1001コメント350KB

バージョン管理システムについて語るスレ4

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2009/05/22(金) 00:02:10

バージョン管理システムについて語りましょう。

●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ～ Rev.3 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r11 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1215565366/
git スレッド [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1197798039/
Bazaarでバージョン管理【bzr>git,svn,cvs】 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1218083381/

●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/

0002デフォルトの名無しさん

2009/05/22(金) 00:03:26

●関連サイト
CVS
http://ximbiot.com/cvs/cvshome/
Subversion
http://subversion.tigris.org/
Git
http://git-scm.com/
Bazaar
http://bazaar-vcs.org/
Mercurial
http://www.selenic.com/mercurial/wiki/
Darcs
http://www.darcs.net/
GNU arch
http://www.gnu.org/software/gnu-arch/index.html
monotone
http://www.monotone.ca/
Visual SourceSafe
http://www.microsoft.com/japan/msdn/ssafe/

●チュートリアル
Subversionによるバージョン管理(日本語訳)
http://subversion.bluegate.org/
Git入門
http://www8.atwiki.jp/git_jp/
Bazaar Documentation Overview
http://bazaar-vcs.org/Documentation
Mercurial の使い方のチュートリアル
http://www.selenic.com/mercurial/wiki/JapaneseTutorial

0003デフォルトの名無しさん

2009/05/22(金) 00:05:18

githubの使い方を勉強するために、
誰か一緒にやりませんか？

ローグのPHP版を作るプロジェクトを。

0004デフォルトの名無しさん

2009/05/22(金) 00:07:41

Subversion r11 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1230488758/

すまん、URLだけ間違えた

0005デフォルトの名無しさん

2009/05/22(金) 00:10:57

ci -m '乙'

0006デフォルトの名無しさん

2009/05/22(金) 01:08:11

＼
　ヽ、　　　_ノ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　｀'ｰ '´
　　　　　○
　　　　　　Ｏ
　　　　　　　o
　　　　　　　　　　　　　　　　　　　　　　　　　　 , ‐'''^^"'''ー､、
　　　　　　　　　　　　　　　　　　　　 ._..-'"￣￣フ′　　　　　　　｀'‐､
　　　　　　　　　　　　　　　　　　　.／　　　　　/　　　　　　　　　　　　＼
　　　　　　　　　　　　　　　　　　/ 　　　　　　.!　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　｡'i　　　　　　!　　　　　r',ヽ　　　　　　　,!
　　　　　　　　　　　　　　　　　i'ﾞ　　　　　 | 　　　ヾ'-'　　　　　　 .l
　　　　　　　　　　　　　　　　　 '､　　　　　　 , '、　　　　　　　　　　　,l.
　　　　　　　　　　　　　　　　　　､　　　 ,‐'　　ヽ、　　　　　　　　　 ,/
　　　　　　　　　　　　　　　　　　｀'┬ ' ´　　　　　ヽ、　　　　　　ノヽ　
　　　　　　　　　　　　　　　　　　　　　!　l´r｀---z　　 / ｲ｀'ﾙﾅｻ
　　　　　　　　　　　　　　　　　　　　　ヽ　'ヽ＿__/　　　 /ﾚ
　　　　　　　　　　　　　　　　　　　　　´_＼`‐　　　 ,__,／/ /:___________
　　　　　　　　　　　　　　　　　　　,.r '　　　ー-｀　　'´ - ‐　￣　　　'ｰ､
　　　　　　　　　　　　　　　　　　,/　 _,.　　　　　　　　　　　　　　　　　　ヽ
　　　　　　　　　　　　　　　　　 ,レ' ´　　　　　　　　　　　　　　　　i　　　　　 l
　　　　　　　　　　　　　　　　／　　　　　 ,　　　　　　　　　 ,l　　　　　 l
　　　　　　　　　　　　　　　｡'i　　　　　　 !　　　　 r',ヽ　　　　l l　　　　 l
　　　　 ,､r;,　　　　　　 i'ﾞ　　　　　　 !　　　ヾ'-'　　　　l. l　　　　　l
　　　 _,r'´､l.ﾚ'､　　　　　 '､　　　　　 ,　'、　　　　　　　　 ,/　l　　　　 ,.!v-､,_
　　　l　L.., } 　 ! 　　　　ハ､　　　　 , ‐'　　ヽ、　　　　　　ノ　 /!　　　 /`,/_,l　L,
　　 lﾞl　ﾍ｣/ 　 l.　　　　　/　　｀''┬ ' ´　　　　　｀'ｰ----- '´　,／ l　　　/　 !:ｲ､_ﾉ l、

0007デフォルトの名無しさん

2009/05/23(土) 01:00:15

ここ即氏判定あり？

0008デフォルトの名無しさん

2009/05/23(土) 06:36:34

テンプレ追加

Bazaarメインドキュメント（ユーザーガイドやリファレンスの和訳）
http://sarabande.info/doc/bzr

0009デフォルトの名無しさん

2009/05/24(日) 07:58:11

なんだよー、Mercurialにも名前付きブランチあるじゃねーか！はやく教えてくれよ！
チュートリアルみたら、ブランチするのにリポジトリをいちいちコピーしてたから、
ああMercurilaではGitみたいに、リポジトリの中で複数のブランチをもつことはできないんだと
ずっと思っていた。

これでgitを使う理由がなくなった。名前付きブランチ最高!

0010デフォルトの名無しさん

2009/05/24(日) 11:16:42

svnにしとけ

0011デフォルトの名無しさん

2009/05/24(日) 14:08:07

TortoiseHg 0.75なのですが、既存のローカルのリポジトリをcloneすると、
以下のようにファイルごとにWARNINGが出てしまいます。

WARNING: unko/my_fucker.css already has CRLF line endings
and does not need EOL conversion by the win32text plugin.
Before your next commit, please reconsider your encode/decode settings in

cloneした後は特に問題がないようなのですが、ちょっと怖いです。
どういうことなんでしょうか？

Mercurial.ini の内容
[extensions]
hgext.convert=
hgext.win32text=
hgext.win32mbcs=
fixutf8 = d:\software\Mercurial\hg-fixutf8\fixutf8.py

[encode]
** = cleverencode:

[decode]
** = cleverdecode:

0012デフォルトの名無しさん

2009/05/24(日) 15:37:03

>>11
my_fucker.css が CRLF エンコーディングのままリポジトリに入ってるから、
コミットする前に CRLF -> LF の変換がいらないってことだと思うよ。

あと、fixutf8使うなら win32mbcs は外した方がいいと思うよ。

0013デフォルトの名無しさん

2009/05/24(日) 16:45:35

>>12
あー、そういうことなのか…。
エラーメッセージはそのままで「CRLFで入っているから、変換が必要ないよ」ってだけか。

> あと、fixutf8使うなら win32mbcs は外した方がいいと思うよ。
了解です

0014デフォルトの名無しさん

2009/05/24(日) 19:24:10

Windows環境において
Mercurialでfixutfを使おうと思い
http://www.asukaze.net/etc/vcs/hg-fixutf8.html

などのサイトを参考に
hg-fixutf8 を使うようにMercurial.ini の設定を行ったんですが

*** failed to import extension fixutf8 from "C:/Program Files/Mercurial/hg-fixutf8/fixutf8.py": [Errno 22] Invalid argument
というようなエラーが出てしまいます。

Mercurial 1.2.1 で最新の hg-fixutf8 を使っているのですが、
何かほかに設定などが必要なのでしょうか？

0015デフォルトの名無しさん

2009/05/24(日) 19:33:05

どうして茨の道を選ぶのか

0016デフォルトの名無しさん

2009/05/25(月) 09:55:10

>>15
茨の道に立ち向かってこそ、進化するからさ。

0017デフォルトの名無しさん

2009/05/25(月) 11:50:30

日本語環境で、あるいはWindowsでまともに動かない物をあれこれいじりまわしても
得る物は少ないと思うけど、やりたきゃやればの世界とも言える。

0018デフォルトの名無しさん

2009/05/25(月) 12:38:41

オプソ系に参加してSVNは使っているんですが
別件で自分だけでやってるソースの管理をやろうと思っています。
非公開で手軽に運用できる組み合わせってどんな感じでしょうか？

わがままな要求としては自分で鯖は立てたくないんですが
突如サービスを打ち切る怪しさの無い外部の無料鯖で
あれば最強です。

0019デフォルトの名無しさん

2009/05/25(月) 12:41:53

>>18
鯖立てるというか、開発マシンだか今使っているマシンだかでsvnserverを動かすのはだめなの？

0020デフォルトの名無しさん

2009/05/25(月) 12:44:40

>>18
Windows なら TorotiseSVN 最強。

0021デフォルトの名無しさん

2009/05/25(月) 12:44:52

>>18
svnだろうが、hgだろうが、gitだろうが、bzrだろうが、ローカルのファイルシステムにリポジトリ作れるから
それでいいんじゃなかろうか？
ローカルのファイルサーバー上でもいいし。

0022デフォルトの名無しさん

2009/05/25(月) 12:46:39

>>14
どんな風にMercurial.ini書いたの？
部分的にうｐうｐ

Mercurial 1.2.1はTortoiseHg付属じゃないやつ？

0023デフォルトの名無しさん

2009/05/25(月) 13:59:53

tortoisehgは、v1.0.0になってから使っても遅くない

002418

2009/05/25(月) 14:33:04

>>19さん
とりあえずその方向で行ってみます。

>>20さん
オプソの方はTorotiseSVNでアクセスしてますのでクライアントは
これになりますね。

>>21さん
そうみたいですね。

0025デフォルトの名無しさん

2009/05/25(月) 20:05:34

>>22
最初はTortoiseHg付属のものを使いましたが
>14の時と同じエラーが出たので、
TortoiseHgのMercurialをpathから取り除いて
新規にMercurial 1.2.1を公式サイトから取得してインストールしました。

Mercurial.iniで変更したのは、以下の部分だけです。

[extensions]
hgext.win32text =
fixutf8 = "C:/Program Files/Mercurial/hg-fixutf8/fixutf8.py"

hg-fixutf8は
>hg clone http://bitbucket.org/stefanrusek/hg-fixutf8/
で 24日に取得しました。

>hg version
のコマンドだけでも
*** failed to import extension fixutf8 from "C:/Program Files/Mercurial/hg-fixutf8/fixutf8.py": [Errno 22] Invalid argument
というエラーは表示されてしまいます。

0026デフォルトの名無しさん

2009/05/25(月) 21:14:38

>>24
TortoiseSVN はリポジトリ作成も簡単に出来るぞ？

0027デフォルトの名無しさん

2009/05/25(月) 23:12:04

せっかくなら Trac Lightning を導入するに 1 票。

0028デフォルトの名無しさん

2009/05/26(火) 08:43:53

>>25
うちは、TortoiseHg付属のhg(1.2.1)だけど hg-fixutf8 でエラーは出ない
hg --helpしたときにちゃんと enabled extensions: の欄に入っているよ。

うちはこんな感じで大丈夫
fixutf8 = d:\software\Mercurial\hg-fixutf8\fixutf8.py

試してみて欲しいこと
・""でくくらない
・スペースを含むパスを入れない
・パス区切りを / じゃなくて \ にしてみる

0029デフォルトの名無しさん

2009/05/26(火) 10:51:57

なにそれ

0030デフォルトの名無しさん

2009/05/26(火) 12:32:12

TortoiseHg 0.7.5なんですが、少しお聞きします。

hg-fixutf8を導入すると、コマンドラインのhgを使う分には問題ない感じなのですが、
TortoiseHg の GUIから使おうとすると、cloneなどで経過が何もでず、
ウインドウを閉じた時にログ見なさいといわれるので、
C:/Program Files/TortoiseHg/hgproc.exe.log を見ると

Exception in thread Thread-1:
Traceback (most recent call last):
　　File "threading.pyc", line 460, in __bootstrap
　　File "hggtk\hglib.pyc", line 239, in run
　　File "mercurial\extensions.pyc", line 112, in wrap
　　File "T:\usr\local\win\develop\Mercurial\hg-fixutf8\fixutf8.py", line 140, in f
　　File "T:\usr\local\win\develop\Mercurial\hg-fixutf8\win32helper.py", line 84, in rawprint
LookupError: unknown encoding: cp0

などといわれてしまいます。
TortoiseHg では、hg-fixutf8が使えないのでしょうか？

0031デフォルトの名無しさん

2009/05/26(火) 12:49:36

いいかげんにして

0032デフォルトの名無しさん

2009/05/26(火) 13:30:51

誰も私わかってくれない

0033デフォルトの名無しさん

2009/05/26(火) 14:04:18

もういやよ、こんなの

0034デフォルトの名無しさん

2009/05/26(火) 17:40:04

いやよいやよも好きのうち

0035デフォルトの名無しさん

2009/05/26(火) 21:21:04

>>30
GetConsoleOutputCPを非コンソールアプリから呼ぶと0を返すのが問題みたいだね
とりあえず932に決め打ちしてみたら？

0036デフォルトの名無しさん

2009/05/27(水) 00:19:29

FIX: When you run the Visual SourceSafe 2005 Analyze.exe utility to analyze a large Visual SourceSafe database,
the Visual SourceSafe 2005 Analyze.exe utility crashes
http://support.microsoft.com/kb/969517/en-us

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=969517

0037デフォルトの名無しさん

2009/05/27(水) 11:53:34

>>35
サンクス。該当箇所みてみたら確かに、そんな感じですね･･･。

これどこに報告すればいいんだろ？fix-utf8のフォーラムとかってあるんだろか？Issueにいきなり登録しちゃったらまずいかな？

0038デフォルトの名無しさん

2009/05/29(金) 00:31:52

svk終了のお知らせ
lists.bestpractical.com/pipermail/svk-devel/2009-May/001224.html

* 機能追加、性能改善は行わない。
* 少なくとも1年半は最新svnへの対応を続ける。
* svn 1.6対応版は来週リリース。

おつかれさま

0039デフォルトの名無しさん

2009/05/29(金) 22:20:32

>>38
たしかにSVKはおつかれさまだし、そうしたい気持ちも分かるんだけど、
svn同士のマージでは重宝してるんだよなぁ。
Subversionのmerge tracking試してみるかなぁ。

0040デフォルトの名無しさん

2009/05/30(土) 05:26:49

えええっ！
じゃぁ、Windowsでsvnリポジトリを分散環境に持ち出してまた戻すってのを
実現するには、どうすりゃいいんだ？

0041デフォルトの名無しさん

2009/05/30(土) 06:05:02

つ git-svn

0042デフォルトの名無しさん

2009/05/30(土) 07:15:05

マジサンクス。
試してみる。

0043デフォルトの名無しさん

2009/05/30(土) 10:35:47

>>40
bzr-svnとかどうでしょう。
bzrのWindowsインストーラには含まれてます。

0044デフォルトの名無しさん

2009/05/30(土) 12:01:58

>>40
hgsubversionとかどうで(略

0045デフォルトの名無しさん

2009/05/30(土) 14:27:42

次にお前は、日本語のコミットログが変換で(ry

0046デフォルトの名無しさん

2009/05/30(土) 21:12:41

git-svn の完成度は知らない。
hgsubversion はまだ read-only.

bzr-svn は 0.6 (bzr 1.15とセット) でかなり完成度高いけど、
規模の大きいsvnリポジトリをネットワーク経由で取り込もうとすると
キャッシュを全部メモリに置こうとしてしまうので、段階的に取り込む
テクニックが必要。
次のバージョンにはキャッシュの制御が入ると思う。

0047デフォルトの名無しさん

2009/05/30(土) 21:38:38

git-svn の完成度は高い。
どう高いかは知らない。

0048デフォルトの名無しさん

2009/05/30(土) 21:43:22

git-svnはperlで描かれているぐらい完成度が高い。

0049デフォルトの名無しさん

2009/05/30(土) 22:17:41

書かれている言語によってアプリケーションの完成度が決まるとは
ハツミミです

0050デフォルトの名無しさん

2009/05/30(土) 22:46:18

git-svnは使い始めたときはちょっと不安があったけど、
実際使ってみるとまったく問題ないね。仕事で使ってる。
ただ常にsvnにrebaseしていかないといけないので、svnを止めたくなる。

0051デフォルトの名無しさん

2009/05/30(土) 23:42:01

git-svn が今のところ一番使いやすい。たぶん今後も、そうだという気がする。
svnもgitも他mercurialやbazaar等、全部branchやrepositoryの考え方が違う。
考え方が違うものを擦り合せるなら、いろいろ出来た方が上手くいく。
ただ単体で使うなら評価は、また別。

0052デフォルトの名無しさん

2009/05/31(日) 06:01:06

>>51
少なくともコマンド、オプション体系に関しては、gitが他の3つに対して
圧倒的に特殊で覚えにくいと思うけどなぁ。
bzr-svn はかなり透過的にsvnリポジトリを扱えるから使いやすいよ。

0053デフォルトの名無しさん

2009/05/31(日) 11:35:01

そんな中、あくまでdarcsを使う俺なのであった

0054デフォルトの名無しさん

2009/05/31(日) 14:18:01

svn(TortoiseSVN) が日本語に寛容なのを良いことに、俺リポジトリの俺資料メモなどで
コミットログ、ファイル名に日本語使いまくりな私が svk から移行する先で一番スムーズに
行けそうなのはなんでしょうか。

そんなものは無いから死ぬまで svk 、という現状なのかなぁ。。。 orz

0055デフォルトの名無しさん

2009/05/31(日) 16:56:43

>>54
bzr-svn の 0.6 から encode/decode がしっかりされるようになってるよ。
bzrの GUI も開発が停滞気味だったけど最近動きが出てきた。
早ければ今年中にもbzrが最強のsvnクライアントになるんじゃないかな。

0056デフォルトの名無しさん

2009/05/31(日) 17:36:17

bzrはなんかスペックだけは最強で実際は・・・というなんかアレに見える

0057デフォルトの名無しさん

2009/05/31(日) 17:56:12

>>56
まだいろいろ開発中だからねぇ。
bzr 2.0 が出るくらいに移行考えればいいと思う。

0058デフォルトの名無しさん

2009/05/31(日) 18:49:39

分散バージョン管理関係は、WindowsでTortoiseなんとかで日本語対応もとなるとあと二年は必要だな。
TortoiseSVNも3年くらいは不安定すぎてよくOS巻き込んで落としたり、日本語だめだめだったからな。

0059デフォルトの名無しさん

2009/05/31(日) 19:09:13

>>54
UTF-8環境のUnixならどれでも好きなのを選べばいいよ

0060デフォルトの名無しさん

2009/05/31(日) 19:10:36

文字コードはそろそろ統一してほしい

0061デフォルトの名無しさん

2009/05/31(日) 19:59:41

>>60
WindowsはUTF-16、他は全部UTF-8、あとは相互変換、これで9割問題ない。
問題は外人がUNICODEを気にせずアプリを作ってくることだ。
いつの時代も戦争があるように、このアホな訴えは繰り返される。
いつになったら学習するんだか…。

Windowsだと、.NETアプリ＝UNICODEが標準みたいに外人が作っても大体が問題なかったりする環境もあるが、
それ以外だとなかなか統一されない状況だよな。

0062デフォルトの名無しさん

2009/05/31(日) 21:13:21

リポジトリ内での話に限定して
ファイル名はUTF-8で統一していいと思うけど
データは自由にさせてほしいなぁ。

0063デフォルトの名無しさん

2009/05/31(日) 22:40:10

>>61
それほど単純では無いだろ
Macと*nuxでは、同じ UTF-8 でも正規化の方法が違うし
Windowsとは BOM の問題もある

0064デフォルトの名無しさん

2009/05/31(日) 23:26:56

「～」の誤変換も根深いよな

0065デフォルトの名無しさん

2009/05/31(日) 23:42:02

なんで｢～｣じゃないほうのフォントはぐにょってなってるんだ(MSゴシック等)
上下反転じゃだめなのか、それとも区別つきやすいようにわざとしてるのか

0066デフォルトの名無しさん

2009/06/01(月) 00:00:47

>>61
UNICODEなのに日本語通らないプログラム書いてくれるのが、英語圏の人。
Microsoftの名前で出してるのに日本語通らないのあったりするし。

0067デフォルトの名無しさん

2009/06/01(月) 02:39:11

>>61
コマンドプロンプトがUTF-8なりUTF-16にまともに対応してくれれば
いいんだけど。
chcp 65001 とかするとUnicode化して万歳どころか日本語全滅する。

0068デフォルトの名無しさん

2009/06/01(月) 03:03:48

MSはMS専用 UTF規格だから、更に混乱。

しかも、マッピングを重複させているので、
正規のUTFと可逆的な相互変換は事実上不可能。

UTF間ですらコンソーシアムと共通性がない。

0069デフォルトの名無しさん

2009/06/01(月) 05:34:08

MS専用 UTF規格？

0070デフォルトの名無しさん

2009/06/01(月) 10:40:56

>>67
ふと思ったんだけど、PowerShellなら
どうだろうか？

0071デフォルトの名無しさん

2009/06/01(月) 10:43:34

>>70
PowerShellだって、コマンドプロンプト上で動くシェルなのよね・・・
だから日本語をUnicodeで入力とかできない。

いつまでこんなクソ仕様のままにしてるんだろうな、MSは。

0072デフォルトの名無しさん

2009/06/01(月) 10:45:58

M$のOSは日本語の文字コード変わりすぎなんだよ。
sjisなんかcp932なんかunicodeなんかはっきりしやがれ。

0073デフォルトの名無しさん

2009/06/01(月) 10:46:11

>>69
メモ帳でUTF8保存すると分かる

0074デフォルトの名無しさん

2009/06/01(月) 12:05:51

>>73
メモ帳がちょっと異常なだけだろ。

0075デフォルトの名無しさん

2009/06/01(月) 12:06:36

メモ帳がMS規格に無理矢理更新するようになってるんだよね
VisualStudioもそうだけど

0076デフォルトの名無しさん

2009/06/01(月) 12:21:15

MS規格ってなんなの？

0077デフォルトの名無しさん

2009/06/01(月) 12:25:47

>>76
テキストファイルの終端を改行じゃなくいきなりEOFにするとか？

ソースで最後に
}
があるとなんとなくだけど
}[改行]
[EOF]
としたいけど
VSはなぜか
}[EOF]
とするはず

とにかく余計な事をするな

0078デフォルトの名無しさん

2009/06/01(月) 12:27:08

http://d.hatena.ne.jp/hasegawayosuke/20041203/p3
>Unicode が必ずしも必要というわけではないアプリケーションならば、Shift_JIS や EUC-JP を利用するというのも、セキュアな実装へのひとつの手段かも知れません。

0079デフォルトの名無しさん

2009/06/01(月) 12:48:10

>>77
いやそっちじゃなくてMSのUTFというのがわかんない

0080デフォルトの名無しさん

2009/06/01(月) 12:49:16

>>79
ｋｙ

0081デフォルトの名無しさん

2009/06/01(月) 13:16:46

>>78 この文脈でそれを引っ張り出してくる意味がわかんない

0082デフォルトの名無しさん

2009/06/01(月) 14:04:18

>>79
エスパーすると
たぶんBomつきUTF8の事を言ってるのでは

0083デフォルトの名無しさん

2009/06/01(月) 21:44:33

Mercurial で、変更箇所の一部だけをコミットすることはできますか。
Git だと git add -p file.txt とすることで、変更箇所を選択してコミットできます。
同じことをMercurialでできないかなと思い質問しました。

0084デフォルトの名無しさん

2009/06/01(月) 22:08:01

>>82
いまどきそんな勘違いするだろうか

> UTF間ですらコンソーシアムと共通性がない。
とかいってるからもっと違う話だと思うが

0085デフォルトの名無しさん

2009/06/02(火) 13:21:17

>>83
変更箇所ってファイル単位？だったら単純に

$ hg commit -m "hoge." file.txt

でファイル指定すればできるけど。そうでなくて？

0086デフォルトの名無しさん

2009/06/02(火) 13:53:34

>>85
そうではなくて、ひとつのファイルの中に複数の変更箇所があった場合に、
その中から任意の変更箇所だけを指定してコミットする方法です。

たとえばあるファイルを変更したときに、新機能による変更とバグフィックスによる変更とが存在したとき、
まずバグフィックスのための変更だけをコミットし、その次に新機能のための変更を別コミットで登録したい、ということです。

0087デフォルトの名無しさん

2009/06/02(火) 14:29:19

>>86
ある方が珍しいと思う。Git はできるのか。変わってんな。
ほかのバージョン管理ツールは、変更前にブランチなり
クローンなりするスタイルだと思う。

0088デフォルトの名無しさん

2009/06/02(火) 17:41:11

>>86
bzrでは、bzr shelve/unshelveでできますね。
hgにもあったような気がしますが。

0089デフォルトの名無しさん

2009/06/02(火) 17:51:46

Mercurialでもあるってsubversionスレで見た気がする（大昔だが・・・）
でも、bazaarにもあるとは知らんかった、いつの間にか分散VCSでは標準的な機能になってたんだな。

0090デフォルトの名無しさん

2009/06/02(火) 18:08:27

>>86
バグフィックス用と新機能用とにリポジトリを分けた方が幸せになれる気がするんだが。

0091デフォルトの名無しさん

2009/06/02(火) 18:26:38

>>86
その用途はわかるなーGit使ってるけどそういう機能しらなかったｗ
改造目的でソースいじってるうちにバグとか死んでる部分とか見つけちゃって、
ついそのまま流れでやってしまうことあるわ。
改造終わってからやろうとすると、そのまま忘れてしまいそうで。。。

急いでる時はそのまま混ぜてコミット作っちゃったりもするけど、
ちゃんとする時はエディタでundoして２回に分けてコミットしたりしてたｗ

0092デフォルトの名無しさん

2009/06/02(火) 18:42:00

Mercurial Queuesっていうやつかな
ttp://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html

0093デフォルトの名無しさん

2009/06/02(火) 23:46:14

>>86
record extension 使えばできる

0094デフォルトの名無しさん

2009/06/03(水) 03:53:49

>>67
スレ違いになりますが、
WindowsだとコマンドプロンプトのUTF-8の扱い問題が結構痛いですよね。

Windows上でRuby on Railsで開発してますが、UTF-8が扱えないために
けっこう面倒な場面があります。
標準のrails console(Rails用インタラクティブシェル)でUTF-8入力したり表示したりとかがダメポ。
UTF-8のログ表示くらいは出力だけなので、cygwin+UTF-8ターミナルか、もしくはcygwin+UTF-8DLLで行けますが。
一方、rails consoleの方は、readlineのせいかcygwin上からだと何故か使えないし…。(rubyのirbもですが)

Railsに限らず、mysqlのコンソールでも同じだと思います。

chcp 65001は、最近になってから(たぶん、SPがあたってから)使い物にならなくなってしまっている現状。

昨今のwebアプリ開発に不都合多いWindows涙目( ´･ω･`)

0095デフォルトの名無しさん

2009/06/03(水) 09:40:42

>>94
railsってかRubyってコンソールに出力するencodingを自動判別とかしてくれないんだ・・・

Pythonなら print u"あいうえお" とすると、あいうえおという Unicode 文字列を
sys.stdout.encoding (Windowsの場合はcp932) に encode してから出力するから、
cp932にencodeできる範囲では問題ない。
って、これは言語スレの話題か。

0096デフォルトの名無しさん

2009/06/03(水) 11:00:52

それ自動判別じゃないし、出力を設定どおりにエンコードするのはRubyでもできるし

0097デフォルトの名無しさん

2009/06/03(水) 11:17:16

>>96
sys.stdout.encoding は自動で設定されている >自動判別
出力を設定どおりにエンコードするのなら、なんでRailsはutf-8のコンソールを
用意しないといけないの?

って、本気で言語スレネタだ、止めようぜ。

0098デフォルトの名無しさん

2009/06/03(水) 11:58:21

ちょいとgitの質問よろしいでしょうか？

　git status

だとコンソールにカラー表示されます。

　git status | less

みたいにすると、カラー表示されません。
less側のカラー対応はすでに行っていまして、ls --color（だっけ）|lessとかでちゃんとカラー表示されます。

そこで、

git config --global color.branch always
git config --global color.diff always
git config --global color.interactive always
git config --global color.status always

みたいにして、常にカラー表示しようとするんですが、
そうすると、周辺ツールなどで予期しない結果がアプリにわたってしまうためか不具合がおきます。
例えば、redmineでgitリポジトリを使うと、コミットログが反映されなかったりします。

そこでお聞きしたいのですが、
・周辺ツールでも不具合がおきない
・git status | lessではちゃんとカラー表示できる(git diffとかも)

両方を両立する方法はないでしょうか？
gitでカラー表示強制するコマンドラインオプションを探していたのですが、見当たりませんでした…

0099デフォルトの名無しさん

2009/06/03(水) 16:36:13

hg convertでsvn->hgに変換しているんだが
hgでリビジョンを指定するときにr1234形式で書く方法ってない？
不便すぎる

0100デフォルトの名無しさん

2009/06/03(水) 18:58:01

>>99
r1234形式のタグを付ければいいんじゃない。簡単なスクリプトで作れそう

0101デフォルトの名無しさん

2009/06/03(水) 21:01:07

>>99
changeset: 1:82e55d328c8c
となっていたときに、以下のどちらでもOKなわけだが。
$ hg log -r 1
$ hg log -r 82e55d328c8c

ttp://www.selenic.com/mercurial/wiki/JapaneseTutorialHistory

0102デフォルトの名無しさん

2009/06/03(水) 21:15:50

>>101
svnのリビジョンのことだと思うぞwww

0103デフォルトの名無しさん

2009/06/04(木) 02:56:33

おれもよくわかってないけど、gitって出力先が端末かどうかで処理を変えているよね。だから・・・

>>98
>そこでお聞きしたいのですが、
>・周辺ツールでも不具合がおきない

こうするには、デフォルトの挙動を変えないようにしたまま、

>・git status | lessではちゃんとカラー表示できる(git diffとかも)

このときだけ強制的にカラー表示するように指定するしかないんじゃないかな。
つまり git diff --color | less とか毎回するわけ。
でもめんどくさいから、$HOME/.gitconfig に
[alias]
　cdiff = diff --color
と書いておけば、デフォルトの挙動を変えないまま git cdiff | less でカラー表示になる。
これくらいが落としどころでしょうか。

0104デフォルトの名無しさん

2009/06/04(木) 03:06:39

>>91
>改造目的でソースいじってるうちにバグとか死んでる部分とか見つけちゃって、
>ついそのまま流れでやってしまうことあるわ。
>改造終わってからやろうとすると、そのまま忘れてしまいそうで。。。

まさにその通りです。

>>93
>record extension 使えばできる

ありがとうございます！これですよね。
ttp://www.selenic.com/mercurial/wiki/RecordExtension
まさに、これがほしいものでした。こんなextensionが標準でついてくるんだから、Mercurialはやればできる子。
さらに、行単位でcommitする・しないを選べるextensionもあるんですね。これは git add -p より便利そう。
ttp://www.selenic.com/mercurial/wiki/CrecordExtension
あざーっす！

0105デフォルトの名無しさん

2009/06/04(木) 20:12:40

>>100
しかたがないので、こんなのを書いてみた：
#!/bin/sh
ERROR() {
echo "*** error ***"
exit 1
}
hg convert ${SVNREPO} ${HGREPO} || ERROR
awk '/^svn:/ {
r=$1
sub(/^svn:[-0-9a-f]*@/, "", r)
print $2 " r" r
}' .hg/shamap >.hgtags-new || ERROR
mv .hgtags-new .hg/localtags

0106デフォルトの名無しさん

2009/06/05(金) 06:58:44

ちょいと疑問点があるんだけど聞かせてくれやしないかい？

・AとBというプロジェクトがある。
・AとBはすごく似ていて、外部依存のDB以外ほとんど同じ構造(違うのは設定ファイルくらいと少しの追加ファイル)
・イメージとしては、AとBは同じCMSを使っていて、一部プラグインと設定ファイルだけが違う
・CMSのアップデートなどがけっこう頻繁かつ面倒なので、片方の影響を簡単にもう片方に反映させるようにしたい
・ただ、AとBの一部の設定は(機密などの理由で)お互い共有したくない

この場合、分散バージョン管理など使うとしたら、
どう運用したもんだろう？
できれば、同じリポジトリから派生させて、
共通化できるところは共通化したいものなんですが
(共通化というかpull、updateで簡単に片方でアップデートしたのをもう片方に適用できないか？とか)

0107デフォルトの名無しさん

2009/06/05(金) 07:02:12

>>106
すいません追加です。
話し聞いたら、普通に管理すれば？という感じなのですが、

> ・ただ、AとBの一部の設定は(機密などの理由で)お互い共有したくない
ここがポイントで、
片方のリポジトリを納入先とか誰かに渡す、などするときに機密情報が入っていると困るので、
同じリポジトリに両方の設定をできれば入れたくないなどという話なのです。

0108デフォルトの名無しさん

2009/06/05(金) 09:15:00

>>107
プロジェクト固有の部分だけ Git ならローカルブランチ、Mercurial なら MQ あたりで管理するのはどうよ

0109デフォルトの名無しさん

2009/06/05(金) 09:16:04

3つリポジトリを用意すればいいじゃん。或いは、下のようなディレクトリ構成にしておいてexport用のスクリプトを準備しておくとか。

root
|
+-config_for_A
+-config_for_B
+-common_sources

0110106

2009/06/05(金) 12:34:29

ありがとうございます。

>>108
ローカルブランチはpushしてもリモートに送られたりしないのかな…？
ちょっと見てみます。

>>109
それも考えたのですが、
Redmineとかのプロジェクト管理ソフトだと1リポジトリしか扱えなくて、どうしたもんだろうというのがあります。

ローカルブランチ調べてたのですが、
git の submodule使ったらもしかしたら、解決できるのかな？

0111デフォルトの名無しさん

2009/06/05(金) 22:46:15

>>110
＞git の submodule使ったらもしかしたら、解決できるのかな？
submoduleはSubversionのexternalsみたいに、リポジトリ内に別のリポジトリの
ものを展開して配置したい時に使う感じなので違うと思う
（たとえばMTとその配下のプラグイン郡）

俺なら>>106のような場合には、まず両方に共通な部分を１つのブランチに
しておいて、アップデートとかのメンテはここで行う。
そんで、各々のプロジェクトではそこからフォークして固有の部分を追加
（Gitならcloneして随時rebase）
あと、共通なリポジトリにはpushできないようにReadonlyにするなりする。
って感じでどうだろね。

0112デフォルトの名無しさん

2009/06/06(土) 09:50:40

>>106
hgならmq使えばできるし、うちでも実際にやってるな。

hg clone repos porjectA
hg clone repos projectB

cd projectB
hg init
hg qnew hoge_patch
==edit==
hg qref -g

あとは必要に応じ
hg qpop -a
hg pull
hg up
hg qpush -a

これで中央レポジトリの最新を共有できてローカルの変更を維持できる。
ローカルの変更をコミットしないで管理したいならおすすめ。

0113112

2009/06/06(土) 09:52:41

おっとミスった。
○ hg qinit
× hg init

0114デフォルトの名無しさん

2009/06/06(土) 14:52:27

>>112
projectBのメンバー間でパッチを共有したいときはどうする？

0115デフォルトの名無しさん

2009/06/06(土) 21:04:46

パッチをレポジトリに入れたらええんでないの？
それがいいのかわからんが

0116デフォルトの名無しさん

2009/06/07(日) 02:49:04

>>105
FreeBSD headでつかってみたら
r193589まであるので
hg log -l1が
2.072u 0.191s 0:02.31 97.8% 1200+1755k 0+0io 0pf+0w
だったのが、.hg/localtagsありだと
7.106u 0.478s 0:07.62 99.3% 1182+1727k 0+0io 0pf+0w
までおそくなった。

0117デフォルトの名無しさん

2009/06/08(月) 02:10:43

subversionリポジトリをmercurialに移行しようとしたができない。
標準添付の hg convert -s svn がどうやってもエラーになる。
やっぱgitにしたほうがいいのか。

0118デフォルトの名無しさん

2009/06/08(月) 02:34:33

bzr-svnを勧めたいところだが、hgを使いたいなら hgsubversion を使うのも良いかもな。
Python の svn から hg への移行では hgsubversion を使うことになりそう。
hg convert は、 http://www.selenic.com/mercurial/wiki/ConvertExtension を見るかぎり、
特にWindowsで動かすのは面倒そうだ。

0119106

2009/06/08(月) 09:07:17

レス遅れた。サンクス

>>111
git の submoduleはちょっと違うのか。プラグインだけ別管理ってときなのね。

gitのrebase知らんかった。調べてみる。

>>112
面白い仕組みですね。hg の mq拡張？ですか、試してみます。

0120デフォルトの名無しさん

2009/06/08(月) 18:05:45

>>118
>hgsubversion

これってmercurialをsubversionのフロントエンドとして使うextensionじゃね?
svnリポジトリをhgリポジトリに変換するものじゃないから、hg convert とは違うような。

0121デフォルトの名無しさん

2009/06/08(月) 21:08:39

hgsubversionはgit-svnやbzr-svnと比べて見劣りがするな。
今のところ一長一短といった感じで、hg,git を廻して使ってるんだが、
hg convert で、git から convert する時、branch が名無し(default)に
なるのは、どうにかならないかな。

0122デフォルトの名無しさん

2009/06/08(月) 21:30:18

『入門Mercurial』(FUJIWARA Katsunori著、秀和システム) を読んでいます。
p.70 に

> 対象となるリビジョンが、「作業領域の親リビジョンの直系の子孫となるリビジョン」の場合、
> 実はMecurialでも未コミットベースのマージを行なうことができます。

とあるんですけど、これの意味が分かりません。
「作業領域の親リビジョンの直系の子孫となるリビジョン」ってどんなのですか？

0123デフォルトの名無しさん

2009/06/08(月) 21:39:54

>>122
glogでいうと
o
|
o
|
@
|
の状態。
作業領域の親リビジョンの直系の子孫となるリビジョンは
@よりも上にあるのoのこと。

0124デフォルトの名無しさん

2009/06/08(月) 22:33:59

>>123
ありがとうございます。
そもそも '作業領域の親リビジョン' という表現がわかんないのですが、
これは現在作業中のリビジョンのことですか？
＃なんで '親リビジョン' と呼ぶのかという疑問が。。。

0125デフォルトの名無しさん

2009/06/08(月) 23:34:53

TortoiseHGは素晴しい
Windowsで使うには種々問題もあるが、Linuxで使う分には問題が無い
hgtk log で、GUI表示しながら、commit は CUIが、現時点で最良かもしれない

0126デフォルトの名無しさん

2009/06/09(火) 01:01:12

>>120
svnのフロントエンドとしてhgを使うといことは、svnリポジトリからhgリポジトリの形で
checkoutできるって事だよね。

0127デフォルトの名無しさん

2009/06/09(火) 12:01:39

>>125
nautilus 連携のやつ？
説明どおりに導入してみたけど、プロパティにカレントバージョンが表示されるだけだ。
Debian lenny だからかな。

0128デフォルトの名無しさん

2009/06/09(火) 12:14:28

>>124
hg parentsがあるから、そういうものだとおもうしかない。
気持ちとしてはこんな感じではなかろうか

w
|
o |
| |
|/
@
|

0129デフォルトの名無しさん

2009/06/09(火) 12:18:45

>>127
nautilus連携は、あまり使ってないな。
TortoiseHG に付属する CLIツールの hgtk だけ使ってる。
hgtk log で立ち上げとくと、commit以外のほとんどのことが出来る。
kdiff3と組合せると、更に使い易い。

0130デフォルトの名無しさん

2009/06/09(火) 12:19:10

0131デフォルトの名無しさん

2009/06/09(火) 14:21:33

>>130
何度もありがとうございます。
working dir がまだコミットされていない仮想的なリビジョンということでしょうか。
うーん、なんかしっくりこない。

0132デフォルトの名無しさん

2009/06/10(水) 09:57:24

>>129
ああ、hgtk ね。いろいろあるからどれかわからなかった。
確かにこれはすばらしい。ログさえグラフで見られれば、
後はコマンドラインで不満はないし。

0133デフォルトの名無しさん

2009/06/10(水) 10:27:32

Perlに逃げられたくせに必死だなｗ
ttp://atmarkit.blog.corp.itmedia.co.jp/archives/50859571.html

0134デフォルトの名無しさん

2009/06/10(水) 11:13:53

>>133
Perfoce必死すぎｗｗｗ

0135デフォルトの名無しさん

2009/06/10(水) 13:48:21

お前ら、git mvならぬgit cp コマンドみたいなのはないんでしょうか？
gitではコピーしたという記録は残せない？

0136デフォルトの名無しさん

2009/06/10(水) 14:56:55

gitで、とある文字列をコミットメッセージに含むようなコミットIDを取り出したいんですが、なにかいい方法ありますか。
mercurialの--template機能がgitにもあればいいんですが。

0137デフォルトの名無しさん

2009/06/10(水) 15:22:00

git log --grep=PATTERN で、パターンをログに含むようなコミットだけを選ぶことができました。

0138デフォルトの名無しさん

2009/06/10(水) 18:10:40

wordやパワーポイントのバージョン管理は無理なのでしょうか
全てバイナリーになってしまうのでしょうか

0139デフォルトの名無しさん

2009/06/10(水) 18:22:02

そうだと思います。
バイナリでもバージョン管理は可能なので、使えばいいと思います。

0140デフォルトの名無しさん

2009/06/10(水) 18:23:48

ごめん、書き方が悪かった。
> 全てバイナリーになってしまうのでしょうか
これについてはその通りです。

> wordやパワーポイントのバージョン管理は無理なのでしょうか
無理ではありません。
バイナリファイルでも問題なくバージョン管理できます。
ただしお使いのバージョン管理ソフトによっては、日本語ファイル名の扱いに問題がある場合があります。

0141デフォルトの名無しさん

2009/06/10(水) 18:37:38

>バイナリファイルでも問題なくバージョン管理できます。
conflictした場合の処理が、テキストファイルの場合よりも面倒になります。

0142デフォルトの名無しさん

2009/06/10(水) 18:39:58

ロックしろよ

0143デフォルトの名無しさん

2009/06/10(水) 18:57:19

branch からの merge での conflict は lock だけでは対応しきれません。

0144デフォルトの名無しさん

2009/06/10(水) 19:03:04

そんなことが出来ると思うお前の脳みそをどうにかしろよ

0145デフォルトの名無しさん

2009/06/10(水) 19:21:48

>>141
たしかにそうでした。ごめんなさい。
バイナリファイルが衝突したときって、どうしたらいいの？
分散型だとロックできないよね。

0146デフォルトの名無しさん

2009/06/10(水) 20:25:52

uze-yo

0147デフォルトの名無しさん

2009/06/10(水) 21:52:01

>>135
Gitはファイルを追跡するのではなくコンテンツを追跡する何たらかんたら
なのでそういう仕組みはなし。
ただコミットを見せるときに、これはどう見ても移動したな、
と教えてくれないこともない。

0148デフォルトの名無しさん

2009/06/10(水) 22:59:44

>>133
Yahoo!って学生だったんだな
MercurialじゃなくてGitを引き合いに出したのは
MercurialだとSunとかMozillaとかXenとかどでかいのたくさんあるからだろｗ

0149デフォルトの名無しさん

2009/06/11(木) 01:33:03

>>145
Wordドキュメントなら、Wordを立ち上げて手作業でマージする

0150デフォルトの名無しさん

2009/06/11(木) 09:07:31

実際おまいらPerfoce知ってた？俺は始めて聞いたわ。

0151デフォルトの名無しさん

2009/06/11(木) 09:17:31

>>150
俺は「Perlは何使ってんだろ」って調べた時に知った
Gitに乗り換えるよりも結構前だけど

0152デフォルトの名無しさん

2009/06/11(木) 09:29:59

社内で使ってるプロジェクトの話は聞いたことある。
アセット管理的な部分も含めて、性能はかなり良い、らしい。

0153デフォルトの名無しさん

2009/06/11(木) 10:43:20

Googleの要求に耐えられるバージョン管理ソフトはPerforceだけ!

実際、Googleではバージョン管理はPerforceのリポジトリが１コだけで、
そこにすべてのプロジェクトをぶちこんでいるらしい。
それでも問題なくスケールして管理できるんだから、すごいよね。

0154デフォルトの名無しさん

2009/06/11(木) 10:46:08

すげえええｗｗ
普通分けるよな…

0155デフォルトの名無しさん

2009/06/11(木) 11:18:04

従業員数万人が1つのリポジトリに同時アクセス・・・
それで問題がないとは、恐れ入った。

つうか、リポジトリをひとつにしている理由がわからんが。

0156デフォルトの名無しさん

2009/06/11(木) 11:41:15

最近Bazaar使い始めました。いいですねこれ。
bzrはちょっと打ちづらいけど…

ところで作業コピー作らないで、リポジトリ直のファイルを弄って
るんですが、そういう使い方でもいいんでしょうかね？

0157デフォルトの名無しさん

2009/06/11(木) 11:55:40

>>156
きっと、君がリポジトリ直と思っているのは作業コピーだよ。
bzr init-repo じゃなくて bzr init したでしょ? それは stand-alone といって、
作業コピーの中の .bzr/ 以下にリポジトリが一個付いてくる形式。

0158デフォルトの名無しさん

2009/06/11(木) 12:03:37

Perforce は会社で使ってるけど、管理者じゃないので、GUI がよくできてるく
らいしかわからないなあ。

リポジトリとローカルの作業コピーの対応関係がサーバー側に記憶されていて、
別なマシンからも見られるのはおもしろいと思った。

0159デフォルトの名無しさん

2009/06/11(木) 12:39:02

http://itpro.nikkeibp.co.jp/free/NC/NEWS/20010712/3/
Perforceは１ライセンス１２万円？
２００１年の記事だけど
今はいくらぐらいなんだろ

0160デフォルトの名無しさん

2009/06/11(木) 12:50:41

>>159
http://www.perforce.com/perforce/price.html

商用だけれど JIRA などのツールが対応してくれているのも大きいと思う。

0161156

2009/06/11(木) 13:10:30

>>157
はい、おっしゃる通り bzr initのほうです。
この場合はSubversionのリポジトリとはちょっとイメージが違う感じ？

Subversion使ってた頃は、
リポジトリ作って、そこにインポートして、チェックアウトして…と面倒な感じでしたが、
Bazaarだとチェックアウトしないでそのままのディレクトリで作業できるのがいいです。
自分で使う分にはもうSubversionには戻れませんね。

0162デフォルトの名無しさん

2009/06/11(木) 23:21:48

>>155
上でも出ててけど、
はてなも確か以前はSubversionの1つのリポジトリだったはず・・・

0163106

2009/06/11(木) 23:34:29

git rebaseをちょっと使ってみているのですが、ちょっと疑問点があり、質問させていただきます。

mergeの代わりにrebaseする(例えば git pull --rebase)
ことで、毎回常にpull元の先頭にパッチをあてた感じになる、ということは、
gitkなどでログを見て確認できました。

そこで、ちょっとテストしていてふと思ったのですが、
pullして何度かコミットした後、
git pull --rebaseすると、
何度も修正して、git rebase --continueを繰り返さないといけません。
こんなものなのでしょうか？

pushしなければ、pull元に変更点があってpullのたびに毎回何度も
git rebase --continue しないといけないと思うと面倒くさすぎるのですが、
なんとかならないのでしょうか？

0164デフォルトの名無しさん

2009/06/12(金) 00:06:31

>>106
git rerere
http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html

0165デフォルトの名無しさん

2009/06/12(金) 06:12:25

>>163
rebaseはコンフリクトしなければ普通に終わるはずなんだけど、
originで修正するようなところをローカルでも変更する（しかもoriginには
取り込まれない）なら、rebaseじゃなくてmergeかもね。
いったいどんな部分でぶつかってるんだろう。。。まさか設定ファイルとか。。。

>>164
rerereなんてしらなかったばい！

0166デフォルトの名無しさん

2009/06/12(金) 08:01:42

おーでかーけでーすかー

0167デフォルトの名無しさん

2009/06/12(金) 09:56:19

レレレのレー

0168デフォルトの名無しさん

2009/06/12(金) 11:46:20

>>164
くわしく。よんでもさっぱり意味分からん。

0169106

2009/06/13(土) 07:28:21

>>164
うーん、よくわかんないや…(´･ω･`)
これでできるのかな

というか、>>106の用件なんですが「共通部分」と「共通部分＋依存部分」とでリポジトリ分けて、
「共通部分＋依存部分」から「共通部分」へ片方向の git pull(fetch, merge)だけで別に間に合う気もしてきた…。
むしろ、「共通部分＋依存部分」から「共通部分」へgit pushしなくする方法ってあるんですかね。
「共通部分」のリポジトリの方に依存部分を注入したくないってだけなんですが。

0170デフォルトの名無しさん

2009/06/13(土) 09:12:17

gitでコミットしたログを再編集することはできないものでしょうか？

Redmineなどプロジェクト管理ツールなどで、コミットログに"refs #13"のように書いておくと
チケットとコミットログを関連付けられるのですが、これがまたよく書き忘れてしまいます。
コミットした後で気づく、ということがあるのですが、
コミット後のログを編集することはできないものでしょうか？
pushなどはしていないものとします。

0171170

2009/06/13(土) 09:24:05

>>170
調べてました。
直近なら、
　 git commit --amend
で修正できるんですね。
過去のはさすがに無理ですよね？

Redmineだと何故かキャッシュのせいか、前のコミットが残っているけど、ま、いいか…。

Gitの使い方メモ | appling weblog
http://appling.sakura.ne.jp/wordpress/archives/1332

0172170

2009/06/13(土) 09:38:46

>>170ですが、この辺が参考になりました。

Git ユーザマニュアル (バージョン 1.5.3 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#fixing-a-mistake-by-rewriting-history

Git ユーザマニュアル (バージョン 1.5.3 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#cleaning-up-history

>>171の
> 過去のはさすがに無理ですよね？
は、簡単でスマートに行く方法はないっぽいですね…。

0173デフォルトの名無しさん

2009/06/13(土) 09:52:06

>>172
あるよ

0174デフォルトの名無しさん

2009/06/13(土) 09:58:03

過去のコミットログを編集すると、コミットIDも変わっちゃうんだよね。
そうなると、そのコミットを親とする子コミットもIDが変わっちゃう(参照する親コミットIDが変わる→子コミットの内容が変わる→SHAによるハッシュ値が変わる

0175デフォルトの名無しさん

2009/06/13(土) 10:01:09

ごめん、途中ダッタ。

過去のコミットログを編集すると、コミットIDも変わっちゃうんだよね。
そうなると、そのコミットを親とする子コミットもIDが変わっちゃう(参照する親コミットIDが変わる→子コミットの内容が変わる→SHAによるハッシュ値が変わる)。
だから、あるコミットのログを変更すると、それ以降のすべてのコミットIDを変更しなければならない。

コミットIDがSHAによるハッシュ値であり、その計算にコミットログも含まれるから、コミットIDの変更無しにログを編集するのは無理だろうね。

0176デフォルトの名無しさん

2009/06/13(土) 10:04:38

こんな方法もあるけど、自己責任で。特に5と6。

1. git format-patch XXX で対象コミットまでのパッチを作成
2. git reset --hard XXX でそれまでのコミットをなかったことに
3. git checkout --amend でログを編集
4. git am < patch で、1 で作ったパッチを適用
5. git push origin :master で共有リポジトリのmasterブランチを削除(!)
6. git push origin master で共有リポジトリにmasterブランチを追加

つーか、チケット番号はログじゃなくてタグにしたほうがよくね？

0177デフォルトの名無しさん

2009/06/13(土) 10:10:22

reset → amend → rebase

0178デフォルトの名無しさん

2009/06/13(土) 10:32:31

>>172
WEB+DB PRESS Vol.50のGit特集にあった、
git rebase -i
を重宝してる。
便利なんだが使い方が複雑で、説明難しい…。

0179デフォルトの名無しさん

2009/06/13(土) 10:47:02

>>177
>reset → amend → rebase
最後のrebaseが分からない。git commit --amend したあと、rebaseをどう使うのでしょうか。

0180デフォルトの名無しさん

2009/06/13(土) 11:02:35

>>179
自分でやってみたほうが理解が早いと思うので一つだけ。
reset で過去の履歴に遡って、amend 付きcommitをすると、その場所から
別のブランチが発生する。後は二つのブランチを rebase で一つにする。

0181デフォルトの名無しさん

2009/06/13(土) 11:16:49

>>180
そうすると、amend前の古いログをもったコミットが残ってしまうんじゃない?
違うかな。

0182デフォルトの名無しさん

2009/06/13(土) 14:20:26

>>178
こんなのひっかかった。

> 二つ以上前のコミットを書き換えたいとき
>
> git rebase -i HEAD^^
>
> interacive rebaseらしい
> 修正したいコミットを pick から edit へ修正
> 書き換えする
> 書き換えが終わったら
>
> git commit --amend # コミット書き換え
> git rebase --continue # 以後のコミット書き換え

絶対復習：authorNariさんの復習表示
http://www.takao7.net/brushup/authorNari/show/687

0183デフォルトの名無しさん

2009/06/13(土) 23:55:35

>>182
なるほど、rebase -iは便利そうだね
おれはこの方法でやってた
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/user-manual.html#rewriting-one-commit
この方法は間違えるとかなりぶっ壊すことになるので必ずcheckout -bとかして
バックアップしておかないとこわい。

>>169
＞むしろ、「共通部分＋依存部分」から「共通部分」へgit pushしなくする方法ってあるんですかね。
ローカルやsshならアクセス権で調整するとか、git-daemonで公開とかしたらpushできないと思うよ。

0184デフォルトの名無しさん

2009/06/15(月) 21:17:12

毎回
git push origin master
をしているんですけど、これを
git push
で済ませるにはどうしたらいいんでしたっけ。

0185デフォルトの名無しさん

2009/06/16(火) 13:10:28

>>184
Bazaarならリポジトリ内で
bzr push
すれば最後にpushした外部リポジトリへ自動的にpushしてくれるけど、
Gitも似たようなもんじゃないの？

0186デフォルトの名無しさん

2009/06/17(水) 01:52:06

>>184
http://www.kernel.org/pub/software/scm/git/docs/git-config.html
push.default

Defines the action git push should take if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line. Possible values are:

* nothing do not push anything.
* matching push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default.
* tracking push the current branch to its upstream branch.
* current push the current branch to a branch of the same name.

毎回 git push origin master ってやるほうが安全だとおもうけど

0187デフォルトの名無しさん

2009/06/17(水) 13:14:44

リポジトリのダンプ→フィルタリング→再構築
ができるのってSubversionの他にある？

客先のサーバのパスワードを新人がソースに書き込んでコミットしちゃった
とかの笑えない状況が発生しても対処できるやつ

0188デフォルトの名無しさん

2009/06/17(水) 13:43:46

>>187
gitかmercurialでrebaseすればいい

0189デフォルトの名無しさん

2009/06/17(水) 14:40:42

>>188
たとえば、リビジョン（チェンジセット）が以下のようになっていたとき
A-B-C(最新)
↓
A-C(最新)
と、Bのコミットをなかったことにしたい。
（Bはパスワードをコミットしてしまったリビジョン）
rebaseでできる？

0190デフォルトの名無しさん

2009/06/17(水) 14:57:00

>187
mercurialは、FAQの中に「核ミサイル発射コードをコミットしてしまった時には」
みたいな項目があった気がする。

0191デフォルトの名無しさん

2009/06/17(水) 15:30:29

>>189
git rebase -i HEAD~3
などとして出てきた一覧から要らないの消せば良いよ。

0192デフォルトの名無しさん

2009/06/17(水) 15:43:42

>>190
www.selenic.com/mercurial/wiki/FAQ#FAQ.2BAC8-CommonProblems.I_committed_a_change_containing_nuclear_launch_codes.2C_how_do_I_delete_it_permanently.3F
これか。

0193187

2009/06/17(水) 15:49:44

>>190-192
ありがとう。
git rebase -i
hg clone -r
でできるんだね。

0194デフォルトの名無しさん

2009/06/18(木) 09:08:16

>>190
吹いた
>>192
本当にあるのかよ！

0195デフォルトの名無しさん

2009/06/18(木) 23:12:15

>>193
それじゃないと思うぞ
mq使わないと無理

0196デフォルトの名無しさん

2009/06/19(金) 12:33:10

>>193-195
mq を使い始めると何でもできちゃうから慎重にな。

0197デフォルトの名無しさん

2009/06/19(金) 17:07:08

darcsでコミットするたびにパッチの名前きかれるのがめんどい
その時の日時を自動でいれてくれないのかな

0198デフォルトの名無しさん

2009/06/19(金) 22:10:20

>>194 こっちにもあるよ
ttp://www.selenic.com/mercurial/wiki/JapaneseFAQ#JapaneseFAQ.2BAC8-CommonProblems.A.2BaDhlO2SDMJKITDBGMLMw.2FDDJMJJUKzCTMGBZCWb0MJIwszDfMMMwyDBXMGYwVzB.2BMEQwfjBXMF8wAjBdMIwwkmBSTkV2hDBrUkqWZDBZMIswazBvMGkwRjBXMF8wiTBEMEQwZzBZMEv.2FHw-

0199デフォルトの名無しさん

2009/06/20(土) 18:23:21

このスレ的に一番のお勧めはhgかgitのニ択か？

0200デフォルトの名無しさん

2009/06/20(土) 18:36:28

bzrじゃね?

0201デフォルトの名無しさん

2009/06/20(土) 19:23:05

お勧めはbzrだけど、使ってるのはhgというのがこのスレの傾向。

0202デフォルトの名無しさん

2009/06/20(土) 21:07:11

日本人的には「ファイル名はUnicode」のbzr推奨する所だけど、
分散バージョン管理が盛り上がり始めたころはまだ完成度が
低かったために人気が低い。

hgは「ファイル名はバイト列」という、同じ言語で文字コードが乱立する
国のこと無視の仕様だけど、hg-fixutf8を使って, TortoiseHg をファイル名を
Unicodeで扱うように修正したらなんとかなりそう。

0203デフォルトの名無しさん

2009/06/20(土) 21:48:20

Windowsのこと考えなくていいプロジェクトでは
gitが使われ続けるだろうし、廃れることはないと思う。

一方で、
Windows環境や非プログラマ要員（日本語ファイル名を普通に使う人たち）
のことも考える必要があるプロジェクトでは hg か bzr が候補になるわけだけど、
方向性を考えると bzr のほうが期待できそうな気がする。

というか、後者の分野で bzr が優勢になったら、
hg はどっちつかずで微妙な立ち位置になりそう。

0204デフォルトの名無しさん

2009/06/20(土) 22:22:14

gitはクセが強いから、使いやすいgitとしてhgも使われ続けると思うよ。
Pythonもsvnからhgに移行を決めたし。
Google Summer Code で hg を git のクライアントに使うプロジェクトも
できた。

0205デフォルトの名無しさん

2009/06/21(日) 11:39:28

>>202
bzrはファイル名の文字コードの扱いをやるのはわかったけど、
ファイル本体の文字コード変換もやるの？

例えば、Makefileの中にファイル名書いてたら、
それもちゃんと変換しないとうまく動かない

0206デフォルトの名無しさん

2009/06/21(日) 11:50:47

>>205
ほらそういうのあるじゃん。。。だからファイル名はバイナリのままで
変換なんかしないようが良いと思うよ。ファイルの中身を勝手に変換する
なんてのはもってのほか。。。
文字コードはリポジトリ内ではたいてい統一されてるだろうし、
見る側が調整すれば問題ないと思うんだけど、、、変換必要？

0207デフォルトの名無しさん

2009/06/21(日) 13:56:46

>>205
それはMakefileの問題だから、Makefileに書くファイルは最初から
asciiファイル名を使うべき。

0208デフォルトの名無しさん

2009/06/21(日) 13:59:41

>>206
posix ではファイル名はバイナリが許可されているけど、許可されていない
環境もある。
Makefile の中のバイナリとファイル名のバイナリを維持しても、ASCII以外の
ファイル名をクロスプラットフォームで扱える訳ではない以上、それは詭弁だよ。

0209デフォルトの名無しさん

2009/06/21(日) 14:02:25

>>205
それは、makeがクソなだけ。
antのbuild.xmlみたいになっていれば、ファイル名がネイティブエンコーディングになっていればいい。

0210デフォルトの名無しさん

2009/06/21(日) 14:22:51

>>208
ファイル名にバイナリ使えないってどういうこと？
ASCIIしかだめってことなら、何も問題はないんじゃないの？

0211デフォルトの名無しさん

2009/06/21(日) 15:00:57

文字コードとそのエンコーディング、それにファイル内容の mime-type が
全部ごっちゃに議論されているみたいだぞ。

みんな、もちつけ。

0212デフォルトの名無しさん

2009/06/21(日) 15:14:06

>>210
そう、Makefile をクロスプラットフォームで動かすには ASCII しかだめってことだから、
ファイル名をUnicodeに変換してプラットフォーム間でファイル名の文字化けを
なくしても何の問題もない。

むしろ、変換しないことによって >>209 のいうようにUnicodeに対応したプログラムで
問題が発生する。

0213デフォルトの名無しさん

2009/06/21(日) 16:39:39

>>212
つまりファイル名もリソースもUnicodeで、プログラムもUnicode前提で
ロケール等見て判断してからファイルに到達するようにするなら
ファイル名変換されててもうまくいくだろうってことかね。

でもいったんファイルシステムに書かれてしまったら、どんなロケールで
チェックアウトしたか外部からは分からないし、けっきょくUTF-8あたりに
しとこうって話になるんじゃないか。たとえばWebサーバとかファイル名の
変換までは対応してくれないだろうし。
それだったらオリジナルのバイト列を保持しといたほうが健全だと思うがね。。。

0214デフォルトの名無しさん

2009/06/21(日) 17:08:42

>>213
前半に関してはその通り。
今時、きちんとマルチプラットフォームに対応しているアプリケーションは
そうなっている。逆にそうじゃないアプリケーションではASCIIファイル名
使っておけば良い。

後半に関しては意味不明なんだけど、もうちょっと具体例出せない?
「結局UTF-8あたりにしとこうかな」ってのは、一つのファイルシステムを
共有している環境内では妥当で、「ファイル名はバイナリ列」システムも
「ファイル名はUnicode」システムもうまく行く。
問題は、WindowsをはじめとするロケールをUTF-8に設定できないシステム。

0215デフォルトの名無しさん

2009/06/21(日) 17:09:57

>>213
$ printf '\xe3\x81\x8c' | xargs touch
$ echo *
が
$ echo -n * | hexdump -C
00000000 e3 81 8b e3 82 99 |......|
00000007

UTF-8で良さそうに見えるけど、Mac OS XみたいなOSだとこういう迷惑な仕様
になってるんだよね。

0216デフォルトの名無しさん

2009/06/21(日) 17:17:35

ファイル名のコード体系がまちまちで混在しているというのでなければ
makeが拡張されて
- makefile自体
- コマンド引数
- ファイル名
それぞれのコード体系を指定できるようにすればok

0217デフォルトの名無しさん

2009/06/21(日) 17:45:34

ファイル名をリポジトリメタデータにするときUTF-8に変換しとけば大丈夫って
ことにはならないだろ。

ファイルシステムで使ってるエンコーディングがUTF-8じゃなければラウンドト
リップコンバージョンの問題があるし、winとunixじゃ（MSのせいで）変換表違
うし。

メタデータは元のファイル名をそのままバイナリエクザクトに持つことにして、
変なエスケープだけしないようにするという戦略以外は破綻する。

0218デフォルトの名無しさん

2009/06/21(日) 17:46:41

>>215
そういえば、HFS+はNFD正規化するんだったな。

0219デフォルトの名無しさん

2009/06/21(日) 17:52:33

バイト列+エンコーディングを持ってて適切に変換してくれるならユニコードじゃなくてもいいよ。

0220デフォルトの名無しさん

2009/06/21(日) 18:41:19

>>214
Javaなんかだったらどうにでもしてって感じかもしれないけど、
俺的には「ファイル名はバイナリ列」なシステムのほうが多いんじゃないかって
イメージだったので。
例えばUTF-8なファイル名を想定して作ったWebサイトがSubversionに入ってるとして、
EUC-JPなロケールでチェックアウトしたらファイル名はEUC-JPに変換されるけど、
それってApacheに配備したらリンク切れするんじゃないかと。
そういうわけで実行環境ってやっぱ予め想定された環境で動かすようにするんじゃ
ないかと思って。
で、結局特定のエンコーディングに決めてやるんだったら、リポジトリから
取り出す時のロケールに左右されたりするよりも、オリジナルの状態が
保持されてるほうが気持ちいい。
要は端末側が合わせればいい話、、、って思ってたけど、WindowsがUTF-8に
できないとは知らなかった。

>>215
Macって濁点が別になっちゃうんだっけ。。。おっかねぇ。。。

0221デフォルトの名無しさん

2009/06/21(日) 19:05:30

ntfsはutf-16でfatがcp932なのにファイル名をバイナリエクザクト???

0222デフォルトの名無しさん

2009/06/21(日) 19:25:09

>>221
winってそんなところまでvcsが面倒みてやらなきゃならんの？

0223デフォルトの名無しさん

2009/06/21(日) 19:34:01

>>220
両方とも合法なので、Unicode対応を謳うなら、必要に応じて同一視でき
ないのが悪いんだけどね。

0224デフォルトの名無しさん

2009/06/21(日) 19:47:51

>>222
ファイルシステム内部の文字コードは意識しないしすべきじゃないだろ。
OSの規約を守って入れたものがそのまま出てくるならそれで十分。OSの規約に
沿ったものかチェックするのはvcsだがそれぐらいはしなくちゃな。

0225デフォルトの名無しさん

2009/06/21(日) 20:06:49

>>220
EUC-JPなロケールのApacheがUTF-8のファイル名を想定して
設定ファイルがかかれているの????

0226デフォルトの名無しさん

2009/06/21(日) 22:07:08

>>225
EUC-JPなロケールなのはチェックアウトした人。
Apache自体にロケールってある？　デフォルトキャラセットとかはこの場合関係ないと思うが。

0227デフォルトの名無しさん

2009/06/21(日) 23:15:33

>>226
んじゃあ、Apacheに配備したらリンク切れ云々って何?

0228デフォルトの名無しさん

2009/06/22(月) 02:11:06

>>227
Subversionからチェックアウトした時にファイル名が実質変わってしまうから。

0229デフォルトの名無しさん

2009/06/22(月) 03:24:50

>>228
少なくともASCIIファイル名なら問題ない。

で、ApacheがUnicodeのURL受け取ったときの挙動を知らないんだが、
ApacheがUTF-8を使うとしたら、ロケールをUTF-8に設定した上で
checkout するべき。
EUC の開発環境で checkout したファイルをサーバーにrsyncか
何かでdeployする場合は、deployするときに文字コードを変換して
サーバーに送るべき。
バージョン管理してない非ASCIIファイル名のファイルをその開発環境で
作成できなかったり、文字化けしててファイル名が意味不明になるのは
問題だからね。

ファイル名をバイナリで保存したいというのは限定された環境での話で、
大抵はMacでもLinuxでもWindowsでもファイル名が文字化けすることなく
チェックアウト、チェックインできるようにするのが、汎用的なVCSのあるべき
姿だと思うよ。
限定された環境のニッチなバージョン管理ソフトとしてgitがファイル名を
バイナリで保存するのは別に良いけどさ。

0230デフォルトの名無しさん

2009/06/22(月) 09:42:35

>>229
＞EUC の開発環境で checkout したファイルをサーバーにrsyncか
＞何かでdeployする場合は、deployするときに文字コードを変換して
＞サーバーに送るべき。
だからさ、けっきょく意図された文字コード（たいていはUTF-8）に変換して
配備するんだったら、始めから変換する必要なんてないだろうってこと。

＞限定された環境のニッチなバージョン管理ソフトとしてgitがファイル名を
＞バイナリで保存するのは別に良いけどさ。
GitがWindowsのことを考えてあげてないのはその通りだと思うけど、
だからといって「ニッチなバージョン管理ソフト」という認識は間違いだと
思うぜ。採用実績をみてごらんよ。

0231デフォルトの名無しさん

2009/06/22(月) 10:01:18

>>230
> ＞EUC の開発環境で checkout したファイルをサーバーにrsyncか
> ＞何かでdeployする場合は、deployするときに文字コードを変換して
> ＞サーバーに送るべき。
> だからさ、けっきょく意図された文字コード（たいていはUTF-8）に変換して
> 配備するんだったら、始めから変換する必要なんてないだろうってこと。

開発環境でファイル名が文字化けするのが問題だって上で書いてるだろ?
rsync に iconv オプションつけるくらい、ファイル名が文字化けした環境で
開発するのに比べたら全然手間じゃない。

> ＞限定された環境のニッチなバージョン管理ソフトとしてgitがファイル名を
> ＞バイナリで保存するのは別に良いけどさ。
> GitがWindowsのことを考えてあげてないのはその通りだと思うけど、
> だからといって「ニッチなバージョン管理ソフト」という認識は間違いだと
> 思うぜ。採用実績をみてごらんよ。

ascii しか使わないか、Linuxの事しか考えないプロジェクトでしか使えない
じゃん。
OSSで最近流行ってるのは知ってるけど、OSS以外も含めればまだまだ
svnに比べてニッチだろう。特に日本ではさ。

0232デフォルトの名無しさん

2009/06/22(月) 10:40:37

bzrはよさそうだけど名前から糞esrを思い起こさせるのがいただけない

0233デフォルトの名無しさん

2009/06/22(月) 10:57:18

alias esr=bzr

0234デフォルトの名無しさん

2009/06/22(月) 11:07:16

>>222
そんなことはない。
Windows APIはファイルシステムの内部エンコードには関係なく、UTF16の文字列を返す。

0235デフォルトの名無しさん

2009/06/22(月) 11:13:23

リポジトリ内のファイル名がバイナリか文字列かってポリシーも大事だろうけど、
実際のところバイナリのままでももうちょっとうまくやれるはずなんだよな。

WindowsのAPIはUTF16の文字列でパスを返すんだから、この文字列をそのままUTF8に変換してくれれば、
GitやMercurialでも実用上問題ないレベルでUNIX系と相互運用できるはず。
UNIXの場合はファイル名＝バイナリのままで、Windows側だけで対処できるからリポジトリの構造変えなくていいし。

ただWin9x互換の古いAPI (Ansi API)を使ってると面倒。
旧APIはUTF16の文字列をさらにロケールに合わせて再変換したマルチバイト文字列(日本ならシフトＪＩＳとか)を返す。
現状のGitやMercurialはこの状態なのかな。
こうなるとUTF8にしようにも単純に一対一で変換出来なくなってしまう。

Cの標準関数が内部で古いAPIを使ってるから、意識しないで使ってるとどうしてもこういう問題が起きてしまう。
まぁ今更この辺をUTF8にするのも無理な話だろうが。アメリカ人は現状でも困らないしな…。
Cygwinとかもよく問題になってるな。

0236デフォルトの名無しさん

2009/06/22(月) 11:50:14

>>235
Mercurial は fixutf8 拡張を入れるとW系APIを使うようになるよ。
GUIが子プロセス起動するときにコマンドライン引数をW系API使わないで
送ってるから、GUIはまだ対応できてないけど。

0237デフォルトの名無しさん

2009/06/22(月) 11:51:50

>>235
utf-8 cygwinを使えばgitもW系API使うな。
msys git は無理だけど。

0238デフォルトの名無しさん

2009/06/22(月) 13:47:54

実用レベルに達したWindows向けGitクライアント「TortoiseGit」でGitを始めよう
ttp://sourceforge.jp/magazine/09/06/19/0340248

hg派としてはとてもうらやましいです

0239デフォルトの名無しさん

2009/06/22(月) 16:05:44

>>238
TortoiseHg って、まだダメダメだったりするん？

0240デフォルトの名無しさん

2009/06/22(月) 17:45:51

>>238
うーん...
> 　TortoiseGitでは内部的にmsysgitを使用している。そのため、日本語ファイ
> ル名の扱いも現状ではそれに準じたものとなり、ファイル名はシフト
> JIS（CP-932）で保存される。

0241デフォルトの名無しさん

2009/06/22(月) 18:15:46

結局ファイル名はバージョン管理どれ使うにしてもascii使え、
ascii使えば機能は大差無いから好きなの使っとけってこと？

0242デフォルトの名無しさん

2009/06/22(月) 21:17:33

Mac使えば糞面倒な事やらなくてもTimeMachine一発なのにな

0243デフォルトの名無しさん

2009/06/22(月) 21:40:33

>>242
君のは単なる勘違い
他のMacユーザーに迷惑だから認識を改めてくれ

0244デフォルトの名無しさん

2009/06/22(月) 22:03:11

>>238
Windows上だとhgのがずっと筋がいいから遠からず追いつくと思う。
win環境でgitからhgに変えて速いのにびっくりした。

0245デフォルトの名無しさん

2009/06/22(月) 23:16:00

Tortoiseの完成度
Hg > Git > Bzr

0246デフォルトの名無しさん

2009/06/22(月) 23:56:36

Bzr がんばれ
応援してる

Git使いだけど。

0247デフォルトの名無しさん

2009/06/23(火) 01:03:40

>>246
とりあえず日本語ディレクトリ名がだめなのは、bzr自体がUnicodeコマンドラインオプション
受けとるようになったから、TortoiseBZRのバグトラッカーにそれを使うようにするパッチを
置いといた。
それ以外に何か足りてないのがあれば、言ってくれたら暇な時に対応するよ。

今、 BzrExplorer ってのがハイペースで開発されてる。
Tortoiseは重くなるのがいやだからこっちに期待してる。

0248デフォルトの名無しさん

2009/06/23(火) 01:58:03

Tortoiseは統合してくれないかなぁ…

0249デフォルトの名無しさん

2009/06/23(火) 07:30:32

>>238
飛ばし記事乙
何が、実用レベルだ。

>>240の問題があり、>>237しないといけなくて、
TortoiseGitではUTF-8 cygwinは微妙に対応が変
UTF-8日本語ファイル名は化けたり、オーバーレイアイコンが付かなかったりするする

0250デフォルトの名無しさん

2009/06/23(火) 07:35:30

>>242
何が一発なの？MacでWindowsの日本語ファイル周りの問題を解決できるの？

0251デフォルトの名無しさん

2009/06/23(火) 09:01:57

正直、もう Explorer にくっついてる意味無いと思うんだよね。
ほとんど作業用のウィンドウ開くだけじゃん。
WinCvs のような独立アプリがいいんだけどなあ。

0252デフォルトの名無しさん

2009/06/23(火) 09:51:36

>>251
つBzrExplorer
まだ一般向けベータになったばかりだけどね。

Tortoiseの欠点は、ファイルやディレクトリ一つ一つにオーバーレイをするかどうかを
問い合わせるので、PC全体の動作が遅くなること。
同じシェル拡張でも、「このディレクトリでBzrExplorerを開く」を出すくらいだと
軽くていいのにな。

0253デフォルトの名無しさん

2009/06/23(火) 09:54:51

>PC全体の動作が遅くなること。
どんだけしょぼいマシン使ってるんだよｗ
オーバーレイの設定次第でやたら重くなったような気もするけど
デフォルトで使ってる限り欠点として挙げるほどのものでもないよ。

0254デフォルトの名無しさん

2009/06/23(火) 09:57:33

TortoiseSVNの話だが、最近はそれほど気になる速度低下はないよ。
キャッシュとか色々工夫してるみたい。
少なくともワーキングフォルダ外ではToetoiseの影響は感じない。Explorerのクラッシュも見ないし。

むしろ速度重視のせいか、オーバーレイアイコンがちゃんと更新されてない場合も多いがｗ

0255デフォルトの名無しさん

2009/06/23(火) 10:02:17

>>253
svn みたいに各ディレクトリに .svn ディレクトリがあるとまだマシなんだけど、
hg/bzr/git みたいにルートにしか管理リポジトリが無いと、あるディレクトリ
アイコンのオーバーレイをするには、

1. そのディレクトリ自体がリポジトリじゃないかチェックする
2. そのディレクトリの親やさらにその親に .?? がないか探す
3. 1か2であったら、リポジトリを開く
4. リポジトリの内容を検索し、該当ディレクトリがバージョン管理されているか
確認する。
5. 管理されていたら、そのディレクトリの中の子ディレクトリ、孫ディレクトリを
再帰的にチェックしていき、一つでも変更されているファイルが無いか
確認していく。あればそのディレクトリは変更されているアイコンを、なければ
up to date アイコンを表示する。

って感じで、親方向にも子方向にもトラバースしないといけないんだよ。
SSD じゃないノートPCだとHDDのランダムアクセス遅いから明らかに重くなる。

0256デフォルトの名無しさん

2009/06/23(火) 10:04:10

>>254
svn は .svn が分割されているから速いんだよね。
もちろん、他の Tortoise 系が重いのはまだキャッシュ管理が
適当だったりするのもあるんだけどさ。

0257デフォルトの名無しさん

2009/06/23(火) 10:24:54

そもそもエクスプローラから操作できてもあんまりうれしくはないんだよなあ。
統合環境使うならそっち経由で操作できることの方が重要だし、
キーボードでコーディングしている以上、別にコマンドラインでも苦にならないし。

0258デフォルトの名無しさん

2009/06/23(火) 12:50:21

まあ、実際俺も、不具合多すぎて、コマンドライン版ばかり使ってるわｗ

0259デフォルトの名無しさん

2009/06/23(火) 13:43:00

ちなみに、Unicode対応をうたうbzrは今までコマンドラインオプションを
コードページでデコードしていたのでコードページに対応していないUnicode
文字はコマンドラインから指定できなかった。
1.16 からは、 GetCommandlineW() を使うようになって、cp932で表せない
ファイル名もコマンドラインで扱えるようになった。

hg の場合は fixutf8 拡張を入れると、GetCommandlineW() を使ってくれる。
git の場合はutf-8 cygwin で同じく可能だった。
二次配布とか拡張に依存しないのは素晴らしいけど、もっと早く対応しろよ>bzr

0260デフォルトの名無しさん

2009/06/23(火) 13:54:57

>>259
hg/bzrでのsys.argvの問題はpython側の実装が根本的な原因。GetCommandlineWを直接呼ぶのはハックの一種。
gitは言わずもがなcygwin側の問題。utf-8 cygwinを本家にマージさせようとする奇特な人は皆無。

0261デフォルトの名無しさん

2009/06/23(火) 14:42:18

utf-8 cygwinじゃなくて、cygwin-1.7系だと何かマズいんかな。

0262デフォルトの名無しさん

2009/06/23(火) 14:45:49

>>260
Python 3.0 では、 main(int argc, char** argv) が wmain(int argc, wchar_t** argv) になって、
何もしなくてもUnicode文字列が得られるんだけどね。
まだまだ Python 2.x が主流だから仕方ない。

0263デフォルトの名無しさん

2009/06/23(火) 20:40:41

bazaarでssl client cert file はどこで指定するんだ？

0264デフォルトの名無しさん

2009/06/23(火) 21:02:48

>>263
SSL って?
bzr webdav で https 経由で push するとか？

0265デフォルトの名無しさん

2009/06/24(水) 14:44:25

linux板から

ファイルの先頭部分のコメントあたりで
　/*
　 ....
　 * $ Header:　...　(なんかかいてある) $
　 */

これってバージョン管理ソフトに読ませるための情報だったんですね
どのバージョン管理ソフトも対応してるのかな

0266デフォルトの名無しさん

2009/06/24(水) 18:45:01

>>265
してない。
してるほうが少ないのでは。

0267デフォルトの名無しさん

2009/06/24(水) 18:53:43

>>265
rcs、cvs、svn(標準で無効)、git(標準で無効)、bzr (bzr-keywordsプラグイン・標準で無効)は対応してたはず。hg? 知らね。

0268デフォルトの名無しさん

2009/06/24(水) 19:07:25

hgは拡張で対応
ttp://mercurial.selenic.com/wiki/KeywordExtension

0269デフォルトの名無しさん

2009/06/24(水) 23:06:17

バージョン管理ソフトに読ませるための情報じゃなくて、
バージョン管理ソフトが人間に読ませるための情報じゃないの？

0270デフォルトの名無しさん

2009/06/25(木) 01:31:13

>>175
> 過去のコミットログを編集すると、コミットIDも変わっちゃうんだよね。
> …
> コミットIDがSHAによるハッシュ値であり、その計算にコミットログも含まれるから、
> コミットIDの変更無しにログを編集するのは無理だろうね。

よく分からないのですが、IDが対応したリビジョンを一意に特定できれば良いのだから、
後からログを変更したとしても、IDを再計算する必要はないのではないでしょうか。
ログが変更できない理由になっていないと思うのですが、どうなのでしょう。

0271デフォルトの名無しさん

2009/06/25(木) 01:53:26

>>270
IDがハッシュ値だっていう意味はわかってます?

0272デフォルトの名無しさん

2009/06/25(木) 02:19:12

>>271
そうか、ハッシュが衝突するログを掻けばいいのか。

0273デフォルトの名無しさん

2009/06/25(木) 05:59:46

>>270
>IDが対応したリビジョンを一意に特定できれば良いのだから、

原理的にはそうなのですが、分散VCSでは複数のリポジトリが互いに独立して存在するので、
再計算しない場合は、同じIDなのに内容が異なるリビジョンの存在を許してしまいます。
それはまずいので、再計算する必要があります。

これが分散型でないなら、ID発行元が一元管理されているので、再計算の必要はありません。

0274デフォルトの名無しさん

2009/06/25(木) 23:00:40

>>273
なるほど～。良く分かりました。

となると、ログを後から楽に変更できる分散VCSを作ろうと思ったら、
ハッシュ値の計算にログの情報を含めなければいいんですかね。
でも、ログもリビジョンの重要な要素だと考えるなら、この設計はまずいかもしれませんね。

ありがとうございました。

0275デフォルトの名無しさん

2009/06/25(木) 23:27:52

>>274
>ハッシュ値の計算にログの情報を含めなければいいんですかね。
その設計はありだと思います。
あるいは、コミットとはべつにあとからログを付加できる仕組みを追加するとか。
たとえばどのVCSでもコミットに対してあとからタグを付けられますけど、
これと同じ感覚でログをあとから付けたせるようにし、それがあればそちらを優先して表示するけど
なければコミット時のログを表示する、というのでもいいかもしれません。
なんというか、コミットに対してあとからメタ情報を付加できる仕組みがほしいですよね。
タグはちょっとプリミティブすぎる。

0276デフォルトの名無しさん

2009/06/26(金) 00:41:48

ハッシュ値の計算に親コミットIDを含めずに計算するとかはどうかな。
これだと、データを変更したコミットのIDと、その子コミットの親コミットIDを変更するだけで、
子以下のコミットのIDを再計算しなくても良いはず。

編集していない子以下のコミットのIDを変更してしまうのには多少違和感があるけど、
（同じコミットにもかかわらず、他のリポジトリのコミットとIDが変わってしまう）
これだと回避できるかな。
mergeの処理もこの方が速いかもしれない。
もっとも、後からデータを変更する需要がどれ程あるかは分からないけど。

0277デフォルトの名無しさん

2009/06/26(金) 00:58:26

>>276
分かりにくい表現ですみません。
一応訂正。

> 編集していない子以下のコミットのIDを変更してしまうのには多少違和感があるけど、
編集していない子以下のコミットのIDを再計算して変更してしまうのには多少違和感があるんだけど、

0278デフォルトの名無しさん

2009/06/26(金) 02:29:30

Gitの場合だけど、ログの内容もコンテンツも全て同一でコミットし直しても
ID変わっちゃうんだよね…ID作る時に日時も使ってるからだと思うんだけど。
親が同じでコンテンツの内容も同じなら同じIDでもいいんじゃないかな～とは思う。
ただログの内容が違う場合はID変わるのはしょうがないかな～
世界中で同じコミットだとして認識するにも関わらずログの内容がばらばらだと
ちょっとおかしなことになりそう。ログを考えなければ同じモノなんだけどねぇ。

0279デフォルトの名無しさん

2009/06/26(金) 13:04:25

git の仕様を分散VCS一般みたいにされてもな・・・
Bazaar は sha1 じゃなくて uuid を使って、
その代わりにコミットに署名をできるようにしている。

0280デフォルトの名無しさん

2009/06/26(金) 13:13:24

これは……

0281デフォルトの名無しさん

2009/06/26(金) 14:43:54

>>279
>Bazaar は sha1 じゃなくて uuid を使って、

違いを詳しく教えてください。uuidとやらを使うと、コミットの内容とは関係なくコミットIDを発行できるということ？

0282デフォルトの名無しさん

2009/06/26(金) 17:17:02

>>281
コミットの内容と関係ない revid は発行されるが、昔のコミットのコメントを
書き換えるようなコマンドは無いな。

ちなみに、普通は長い revid ではなく短くてブランチローカルの revno を
使って作業する。

0283デフォルトの名無しさん

2009/06/26(金) 22:10:48

>>278
>ID作る時に日時も使ってるからだと思うんだけど。
>親が同じでコンテンツの内容も同じなら同じIDでもいいんじゃないかな～とは思う。
お前アホだろwww

0284デフォルトの名無しさん

2009/06/27(土) 03:08:03

Bazaarは署名+擬似乱数をIDにしてる訳ね。
それなら、コミットの内容を後から変更したとしても、
GitのようなIDの再計算はいらないな。

0285デフォルトの名無しさん

2009/06/27(土) 06:13:52

>>283
くわしく

0286デフォルトの名無しさん

2009/06/27(土) 10:25:34

>>284
厳密に言うと、id がハッシュじゃないと同じハッシュのリビジョンを偽装できるから、
誰かがこっそり変なコードを紛れ込ませる事が可能になってしまう。
だから id と別に署名が付けられるようになっているだけで、署名は付けなくても良いし、
署名は id の一部じゃない。

0287デフォルトの名無しさん

2009/06/27(土) 13:38:59

>>286
署名の必要性がいまいち理解できないわ。
そんなに神経質になる必要あるのかな。

例えばsvnに偽装防止の仕組みってあったっけ？

0288デフォルトの名無しさん

2009/06/27(土) 13:43:30

>>287
> 例えばsvnに偽装防止の仕組みってあったっけ？
svnはsshなりhttpsなりで認証しているのが前提だからな

0289デフォルトの名無しさん

2009/06/27(土) 22:30:53

>>287
例えば、 bzr send -o バンドルファイルみたいにすると、バンドルっていう
パッチセット+リビジョン情報みたいなファイルができる。んで、それを
メールで送ったり、掲示板に貼り付けたりするから、man-in-middle に
改ざんされる恐れがある。

まぁ、神経質な人が使えば良い機能。俺は使ってない。

0290デフォルトの名無しさん

2009/06/28(日) 08:00:18

おまえら、悲惨な目にあったんですが、助けてください。

Mercurialで元ファイルがCRLFの改行コードのテキストファイルを突っ込んでいたのですが、
ある日一部ファイルが壊れたので、元に戻そうと hg revert hogeしたわけですよ。

そうしたら、LFの改行コードで元にもどったわけですよ。
途中まで、気づかずにリポジトリ管理下に入れてたアプリがおかしな挙動して、すげー時間くったわけですよ。
LFになったくらいなら、CRLFに変換すればいいんですが、
毎回、取り出した際に、LFになっとるってこんなことあるんですかい？

これって、どうやったら、CRLFそのままで管理してくれるんでしょうか？
もしかして、リポジトリ作り直し…？(; ´д｀)

環境：Windows Vista SP2, Mercurial 1.2.1 (TortoiseHg0.7.5付属のもの)

0291290

2009/06/28(日) 08:20:31

ごめん、一発で解決したｗ

Mercurial.iniに以下のように hgext.win32text とその諸設定を書き忘れてた(´･ω･`)

[extensions]
hgext.win32text=

[encode]
** = cleverencode:

[decode]
** = cleverdecode:

hgext.win32mbcs外す時に一緒にコメントアウトしていたらしい・・・

しかし、hgext.win32text組み込んだ時って、コミットしたファイルがLFでリポジトリに突っ込まれているのか…。
以前にコミットしたのは、全部hgext.win32text組み込んでたんで、LFになってるみたいだ。

この勝手に変換するのって、もしかして、場合によってはヤバくないですか？
例えば、cygwinのshって、LFでないとエラーはくんですが、リポジトリから吐いてCRLFになってるとマズイじゃん？

0292デフォルトの名無しさん

2009/06/28(日) 11:21:47

>>291
そもそもwin32textに頼らなきゃいいんじゃね?
改行コード混在の環境は想定されてないんだし。

0293デフォルトの名無しさん

2009/06/28(日) 11:35:43

>この勝手に変換するのって、もしかして、場合によってはヤバくないですか？

この手の変換って悩ましいけど
まぁよくあることなので
慣れちゃうんじゃないかなー

0294290

2009/06/28(日) 16:55:00

>>292
> 改行コード混在の環境は想定されてないんだし。

だよねーだよねー

そうか、win32textを始めからつかわなきゃいいのか。
でも、そうすると過去にwin32textで入れた奴だけwin32text使うわけか。
イチイチきりかえ面倒クセー！！
悩ましいなｗ

0295デフォルトの名無しさん

2009/06/28(日) 17:12:00

>>294
1. win32text を外す
2. checkoutし直す
3. LFになってるファイルを全部CRLFに書き換える
4. commit

0296290

2009/06/28(日) 20:12:02

>>295
やっぱりそれしかないか…

0297デフォルトの名無しさん

2009/06/29(月) 09:36:16

>>291
> この勝手に変換するのって、もしかして、場合によってはヤバくないですか？

今ごろこんなこと言う奴がいるとは驚いたな。
テキストの場合、行単位での管理として特定の改行コード(たいていは LF)でリポジトリは統一、
チェックアウトの際に、それぞれのプラットホームに合わせて改行コードを変更。
至極当然な動作だと思うがね。

0298デフォルトの名無しさん

2009/06/29(月) 09:54:05

少しお聞きいたします。

git で普段 pull, push するのはリモートA で、
ある時だけ、リモートB から pull を指定したいということはどのようにしたら可能でしょうか？
リモートAは自由に出し入れ(マージというか)するのですが、
リモートBにはpushしたくないので、指定した時のみ片方向にpullしたいという感じです。

0299デフォルトの名無しさん

2009/06/29(月) 11:06:27

>>291
＞この勝手に変換するのって、もしかして、場合によってはヤバくないですか？
俺はヤバいというより気持ち悪いね。勝手なことはして欲しくない。
ソースコード内の改行なんて、エディタに任せとけばいいよ。

>>298
git pull リモートB master
とかすればいいと思うよ。
http://www.kernel.org/pub/software/scm/git/docs/git-pull.html
http://www.kernel.org/pub/software/scm/git/docs/git-push.html

0300デフォルトの名無しさん

2009/06/29(月) 11:34:54

288ではないですけど>>299をみて思い出したので質問します。
git で origin/master と指定するときと origin master と指定するときの２種類が
あるみたいですけど、この違いってなんでしょうか。
どういうふうに使い分けるかよくわかりません。

0301デフォルトの名無しさん

2009/06/29(月) 11:52:03

>>300
origin/master はリモート"origin"の"master"ブランチの指定で、
origin master は<repository>と<refspec>がスペースで区切られて並んでいる状態。
git pull <options> <repository> <refspec>…

0302デフォルトの名無しさん

2009/06/29(月) 12:16:14

>>301
ですから、その違いは何かということなんですけど。
たとえば git pull origin master は OK で git pull origin/master は NG とか
そういう違いがあったとして、なぜ git pull origin/master は NG となるのか。
origin/master を指定できるところには origin master は指定できるのかできないのか、
逆に origin master を指定するところに origin/master と指定していいのかどうか。
できないとしたら、それはなぜか。両者にどう違いがあるのか。

0303デフォルトの名無しさん

2009/06/29(月) 14:22:45

>>302
ですから、origin/masterはブランチなので、<repository> ってなってるところに
指定したらそりゃNGになるということなんですけど。
git pull origin master ==> git pull <repository> <refspec>
git pull origin ==> git pull <repository> （<refspec>は省略）
http://www.kernel.org/pub/software/scm/git/docs/git-pull.html

Git入門 - トップページ
http://www8.atwiki.jp/git_jp/

0304デフォルトの名無しさん

2009/06/29(月) 14:48:55

>>299
改行を統一しないと差分が正しく取れないから変換するしかない。

0305デフォルトの名無しさん

2009/06/29(月) 16:28:40

そもそも win32text という改行を変換するextentionを入れておいて
勝手に変換するというのは難癖だろ

0306デフォルトの名無しさん

2009/06/29(月) 19:01:07

>>304
取れないってことはないでしょ。
改行混合でもちゃんとうまくやって
ほしいなあ。

たぶんsvnはできてるんだよね？

0307デフォルトの名無しさん

2009/06/29(月) 19:54:07

>>306
LFの文書が入ってるところにCRLFの文書がコミットされたら、差分をどういう状態で格納すればいいのかと。

svnも、リポジトリに入れるのは全部LFだよ。入れるときと取り出すときにクライアント側に合わせて自動変換。
最初からWindowsや旧Macの事も考えられてるから、使う側は意識しなくてもうまくやってくれてる。

0308デフォルトの名無しさん

2009/06/29(月) 20:26:07

svnはそんな変換しなくね？

0309デフォルトの名無しさん

2009/06/29(月) 20:47:48

え？

0310デフォルトの名無しさん

2009/06/29(月) 21:13:29

subversion は svn:eol-style で改行の振舞いを決める
default はそのまま
勝手に変えることは無いよ

0311デフォルトの名無しさん

2009/06/29(月) 21:57:35

ttp://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5
デフォルト(=無変換), native (=クライアントに合わせる), CRLF, LF, CR、の5種類だね。

0312デフォルトの名無しさん

2009/06/29(月) 23:43:55

>>303
うーん、伝わらない。
Gitの素人なんで中身はよくわからないままの質問なんですけど、
git pull origin master って、リモートのリポジトリとブランチを指定しているんですよね。
だから git pull origin/master でいいじゃんと思うんですけど、おかしいですか。
git pull origin # リモートリポジトリを指定
git pull origin/master # リモートリポジトリとブランチを指定
素人目からみて、あるコマンドでは git xxx origin/master を使い、
別のコマンドでは git xxx origin master と指定しなきゃいけないのは、
わかりにくくてしょうがいないです。

0313デフォルトの名無しさん

2009/06/30(火) 00:12:47

>>312
乱暴な言い方かもしれないが、思想の違いなんだろうな
同じような機能(元々同じ目的だから)を有するmercurialともリポジトリの
考えが違う
gitのブランチは各々違うレポジトリを差すことができる

0314デフォルトの名無しさん

2009/06/30(火) 04:25:25

>>299
サンクス
指定すればいいわけね。

Cheat Sheetsにもリモートを指定する例がそのまま載ってた。
Git Cheat Sheets JP
http://hail2u.net/documents/git-cheat-sheets-jp.html#remote-repository

つまり、
　git remote add remoteB repos/m_project
　git pull remoteB
ということだな。

>>300
むしろ、origin/masterと指定するときってどんな時があったけ？

0315デフォルトの名無しさん

2009/06/30(火) 09:10:30

>>306,310
ごめん。すっかりeol-style=nativeに慣れきってしまっていた。
無変換だと改行コード混在したらまともにdiffは取れなくなるという話が>>311に載っている。

0316デフォルトの名無しさん

2009/06/30(火) 09:34:10

>>312
$ git branch -a
* master
origin/HEAD
origin/gitk-for-paulus
origin/html
origin/maint
origin/man
origin/master
origin/next
origin/offcuts
origin/pu
origin/todo
いま、ローカルリポジトリのmasterブランチに居る。
リモートリポジトリ"origin"にも、masterという名前のブランチがある。
ただmasterと指定した場合、ローカルリポジトリのmasterブランチのことに
なる。
リモートリポジトリ"origin"のmasterブランチを指定したい場合は、
リモート名付きでorigin/masterとしてあげなければいけない。
git log master はローカルリポジトリのmasterブランチのログリスト。
git log origin/master はリモートリポジトリ"origin"のmasterブランチのログリスト。
git log todo はローカルにはそんなブランチは無いのでエラーになる。
git log origin/todo ならOK。
ごく自然な書き方だと思うんだけど。。。

つかチュートリアル読んだ？

0317デフォルトの名無しさん

2009/06/30(火) 12:00:14

>>312
＞だから git pull origin/master でいいじゃんと思うんですけど、おかしいですか。
origin/masterを指定する書き方だと、git merge origin/master になる。

git pullの書式は git pull <options> <repository> <refspec> だから、
書くとしたらgit pull origin master とかいう感じになるんだけど、
なんでそうなのかというと、pullはfetchとmergeの合わせ技だから。
<repository>はgitが最初にfetchを行うリモート、
<refspec>はgitがmergeを行うブランチ。
で、これらはconfigのbranch.<name>.remote と branch.<name>.merge の設定によって、
それぞれ省略できるようになっている。
git pull remote1 fork1　（remote1をfetchしてfork1ブランチをマージ）
git pull remote1　（remote1をfetchして設定済みブランチをマージ）
git pull （設定済みのリモートをfetchして設定済みのブランチをマージ）

よくあるパターンとしてgit cloneで開始してるとローカルmasterブランチの
remoteはorigin、mergeはmasterに設定されているので、git pull だけで
git pull origin masterと同じことになる。
この状況でoriginの違うブランチからマージしたい場合は git pull origin experimental
って感じになる。

pullの書式は省略してgit pullだけで使った時に便利だから、
分かりにくいなら手動でfetchしてmergeしたほうがすっきりするかも知れない。

0318デフォルトの名無しさん

2009/06/30(火) 12:49:07

>>316
まるっきり外れた回答ありがとうございます。
できればもういちどもとの質問を読んでみてください。
「origin/master」の意味を聞いているわけじゃないです。

>>317
>なんでそうなのかというと、pullはfetchとmergeの合わせ技だから。
なるほど、fetchはリポジトリ名を、mergeはブランチ名を引数にとるから、
pullも引数が別々にわかれているわけですね。
これはわかりやすい説明でした。ありがとうございます。
ただ初心者の観点からいうと、「git pull origin/master」と指定できるようにしたほうが
統一感があってわかりやすいかなと思いました。
（技術的には何の問題もないですし。）

0319デフォルトの名無しさん

2009/06/30(火) 13:01:46

>>318
git pull origin masterと、git pull origin/masterでは意味が違うことにも気づけないの?

0320デフォルトの名無しさん

2009/06/30(火) 13:07:10

>>318
単に使い方を教えて欲しいのか、なぜコマンドがそうなってるのかの理由を
質問してるのか、はっきりしないからなんじゃないかと思うが。
初心者アピールする前に少しはドキュメント読んだほうがいいんじゃない？

0321デフォルトの名無しさん

2009/06/30(火) 13:42:02

なんか難しそうだからgitは触れない方がよさそうだな

0322デフォルトの名無しさん

2009/06/30(火) 13:48:40

Subversionで充分です

0323デフォルトの名無しさん

2009/06/30(火) 13:51:40

RCSで十分とかCVSで十分とかいちいち宣言しなくてもいいような

0324デフォルトの名無しさん

2009/06/30(火) 13:52:09

実際、hg, bzrとgit, darcsは、難度のレベルが違う。
後者は永久に一般受けしないと思う。

0325デフォルトの名無しさん

2009/06/30(火) 13:53:16

>>323
ドキュメントまともに読めないやつはSubversionで十分だと言いたいんじゃ

0326デフォルトの名無しさん

2009/06/30(火) 15:47:44

317のおかげで収まったのに。

>>319
落ち着こう。その2つの書き方は分かりにくいから、後者に統一したほうがいいよねという話。
もうちょっと読解力を持とうよ。

>>320
使い方の質問なんてしてないよ。
あえていえば origin master と origin/master の使い分けについての質問。
もうちょっと読解力を持とうよ。

0327デフォルトの名無しさん

2009/06/30(火) 15:51:21

全部他人のせいなんですよね

( ´Д`) <はぁー・・・

0328デフォルトの名無しさん

2009/06/30(火) 15:53:47

ドキュメントの読解もできない間抜けが何を言っているのやら。
パラメータを二つ指定するのと、一つ指定するのでは意味が違うってなんで判らないの?
折角の>317の解説さえ理解できていないじゃないか。

0329デフォルトの名無しさん

2009/06/30(火) 16:06:25

>>326はやっぱり理解してねえなｗ
＞あえていえば origin master と origin/master の使い分けについての質問。
使い分けとかいうレベルじゃないからｗ別ものｗ
スペースで区切ったら別のパラメータなんですよ～たまたま並んでるだけｗ

0330デフォルトの名無しさん

2009/06/30(火) 21:28:58

>>328,329
そんなに理解するのが難しいこと言っている？
引数を2つ指定している場合でも、gitが引数の解釈をちょっと頑張ればひとつにできて、
かつ他のコマンドと同じ書き方ができると言っているだけなんだけど。

>パラメータを二つ指定するのと、一つ指定するのでは意味が違うってなんで判らないの?
だから、パタメータがひとつでも、指定の仕方で２通りに解釈させることができるってことが分からない？
git checkout なんか引数にファイル名やブランチ名を指定できるでしょ？パラメータをひとつだけ指定した場合でも、
git コマンドが適切に解釈して別々の動作をしてくれるよね。
git の他のコマンドはそのくらい柔軟にコマンド引数を解釈してくれるんだから、git pull も origin と origin/master の区別ぐらいつけたらいいのにという話。

>スペースで区切ったら別のパラメータなんですよ～たまたま並んでるだけｗ
だから、引数の解釈をもう少し頑張れば別々のパラメータにしなくても済むよねという話なんだけど。
＃これふざけて言ってるのかな。それともマジで読解力がないの？ゆとりすげーな。

0331デフォルトの名無しさん

2009/06/30(火) 21:36:07

こんな所で自分の妄想話を披露してる暇があるんなら自分で作れよアホ

0332デフォルトの名無しさん

2009/06/30(火) 21:44:02

>>330
git pull origin master
の origin は remote 'origin' で, master は手許の repository の branch 'master'.
つまり, branch 'master' が track している remote branch と merge をするわけだ.

git pull origin/master
と書けたとして, origin/master は remote 'origin' の branch 'master'.
さて手許の branch のどれを merge するのかな? origin の master を track している手許の branch 全部?

まー, 文句あるならこんなところでぶーたれてないで patch 書いて送ればいいんじゃないの?

0333デフォルトの名無しさん

2009/06/30(火) 21:56:13

>>330
これお前だろ。いつのまにGitのUIを俺好みにしろって話になったんだ？
300 ：デフォルトの名無しさん：2009/06/29(月) 11:34:54
288ではないですけど>>299をみて思い出したので質問します。
git で origin/master と指定するときと origin master と指定するときの２種類が
あるみたいですけど、この違いってなんでしょうか。
どういうふうに使い分けるかよくわかりません。

0334デフォルトの名無しさん

2009/06/30(火) 22:08:08

>>330
だからさ、ちゅーとりある読んだー？
ドキュメント読まずに私初心者ですけど使いにくいですもっとこうだったら
いいと思うって、どんな？
git pullの書式はこう書けたらもっと良いと思うんだけどどうかな？　って
始めから書いてたら、
スルーしてたと思うけど。だってそうは思わないからね。

0335デフォルトの名無しさん

2009/07/01(水) 00:24:00

何か伸びてると思ったら...

0336デフォルトの名無しさん

2009/07/01(水) 01:31:13

>>332
＞master は手許の repository の branch 'master'.
＞つまり, branch 'master' が track している remote branch と merge をするわけだ.
この部分は違うような気がする。masterはリモートのmasterのことだと思う。
<refspec>は<src>:<dst>とも書けて、例えば git pull origin master:test1
とした場合はoriginをfetchした後にoriginのmasterをローカルのtest1 にmergeする。
git pull origin master とした場合は、いま居るブランチにリモートのmasterをマージ。
<refspec>を省略して git pull origin とした場合は今居るブランチがtrackしてる
リモートのブランチをマージ。

だからといって git pull origin/master だと意味が通らないなとは思う。
そうするなら git merge origin/master が意味的に合ってる。
pullはfetchするからね。

ただ最近、git checkout --track -b hack origin/hack ってしないといけなかったのが
git checkout --track origin/hack だけでいい感じにしてくれるようになったりしてるので、
git pull origin/masterでそれっぽく動くようになる可能性もゼロではないかも。
>>330のパッチに期待。

0337デフォルトの名無しさん

2009/07/01(水) 09:41:51

そんなことよりそろそろ出るMercurial 1.3が楽しみだ

0338デフォルトの名無しさん

2009/07/01(水) 10:39:13

>>330
> >>328,329
> そんなに理解するのが難しいこと言っている？

内容は一切読んでないので難しいかどうかはわからんが、説明のやりかたがﾄﾞ下手。
まず、読む気にならない。

0339デフォルトの名無しさん

2009/07/02(木) 12:27:08

hg commit .　が
abort; xxx/yyy/zzz: file not tracked!
となるんだが、仕様変更なの?

0340デフォルトの名無しさん

2009/07/02(木) 12:28:01

hg 1.3 出たね。

0341デフォルトの名無しさん

2009/07/02(木) 12:39:40

>340
俺が気になったとこ
# add patch.eol config setting to work with cross-platform patches
# performance improvements, especially on Windows
# much improved zsh completion
# improved Danish, Japanese, Italian and simplified Chinese translations

今回加わった、サブリポジトリって、bzrとかgitにも有るの？

0342デフォルトの名無しさん

2009/07/02(木) 19:24:21

bazaar の1.16.1も出てるよ！

0343デフォルトの名無しさん

2009/07/02(木) 19:52:40

>>342
おそっ

0344デフォルトの名無しさん

2009/07/03(金) 11:46:00

hg cloneすら失敗するとかどうなってるの？！＞hg1.3

……と思ったらwin32mbcsが有効になってるせいだった
切ったら普通にいけた……

0345デフォルトの名無しさん

2009/07/03(金) 18:02:18

Marcurial 1.3登場、リポジトリをまとめる"サブリポジトリ"
ttp://journal.mycom.co.jp/news/2009/07/03/047/index.html

0346デフォルトの名無しさん

2009/07/03(金) 19:18:22

おーっ、わざわざシェルスクリプト書いてやってたのが
本体機能として実装されそうなんだな。

0347デフォルトの名無しさん

2009/07/03(金) 19:21:21

>>346
今までもforest extensionでほぼ同じ事が出来てただろ

0348デフォルトの名無しさん

2009/07/03(金) 22:56:32

>>347
知らなんだぜよ…。orz
Extension は全然チェックしてなかった。

でも木になってないとダメなのか。微妙だな。
サブリポジトリはどうなんだろう。やっぱり木でないとダメなのかな。
それはそれであるといいんだけど、違ってたらやっぱりスクリプトも必要だな。

0349デフォルトの名無しさん

2009/07/05(日) 12:12:32

Virtual SVN（ver1.71）について質問です。

リポジトリを削除したいのですが、できません。
VirstualSVN Managerでリポジトリを開いて右クリックすると、リポジトリの持ってるファイルは削除できるようなのですが
（ちなみに、Managerから消えてるだけで、DBファイルの実体は残っているようです）、
リポジトリそのものを選択して右クリックメニューから削除しても、10秒くらい反応が返ってこなくなるだけで、
結局消えてくれません。

リポジトリのディレクトリをそのまま消しちゃっても良いのでしょうか？

0350デフォルトの名無しさん

2009/07/05(日) 13:29:07

日本語ファイル名を扱えるWindows GUI環境という条件で、
git,mercurial,bazaarのツール群を試してみたが、現時点では
QGit2.3 + UTF-8 cygwin(又は cygwin 1.7)git が一番マシかな。
というかこれ以外はまだ実運用できるレベルじゃない。
確認してないツールもあるかもしれないから、これは使えるという
ものがあったら教えて。

0351デフォルトの名無しさん

2009/07/05(日) 13:30:09

>>350
bzr 1.16.1 + qbzr の trunk + bzr-explorer

0352デフォルトの名無しさん

2009/07/05(日) 14:10:45

>>351
bzrexplorerはbranchのlocal pathに日本語が含まれると不具合があった
新たなbranchを作る時等
trunkでは直ってるのかな？

0353デフォルトの名無しさん

2009/07/05(日) 15:39:47

hg forgetなんてのが追加されてるのにnewsにはかいてないな。
しかも日本語ヘルプでhg addをみたらhg revertを見ろとなってるし。
gettextでこの辺の管理ってできないんだっけ?
間違ったヘルプを出すくらいなら英語のをそのまま表示してくれよ。

0354デフォルトの名無しさん

2009/07/05(日) 16:13:33

>353
日本語ヘルプで思い出して、Windows版hg 1.3を入れてみたが、
これ、WindowsなのにLANG環境変数の設定が必要なんだな。

しかも、訳が付いてるコマンドって半分もないような。

0355デフォルトの名無しさん

2009/07/07(火) 07:58:32

>>350
あと、2,3年後にきたら少しはよくなったいると思うよ

0356デフォルトの名無しさん

2009/07/07(火) 09:55:02

hg の ML でも bzr が楽しみとかの話題になってるし、依然として開発チームは
Unicode に理解を示さないようだし、hg ダメかな。
bzr 試してみるかな。もう検証疲れたよ…。

0357デフォルトの名無しさん

2009/07/07(火) 10:06:23

Python 3系になればきっと

0358デフォルトの名無しさん

2009/07/07(火) 10:06:57

>>356
開発者の中には、無駄なプライドを背負いこんでるやつらが時々いるんだよな～。
hgのUnicodeも「やらないって言ったらやらない」って感じだと思うな。

0359デフォルトの名無しさん

2009/07/07(火) 10:16:08

まあ英語圏では本来 Unicode は必要なものじゃないから、
気持ちはわからないでもないんだけど、全世界で使われるものである以上、ねえ。
bzr は配慮してくれてるわけだし。
はー、bzr 用の仮想マシン用意するか。データはどうするかな…。

0360デフォルトの名無しさん

2009/07/07(火) 13:00:52

>>359
＞全世界で使われるものである以上
それはいいがかり。
向こうには使わせる義理も、こっちには
使う義理もないのだから。

もうとっとと見切りをつけるべきでは。
かわりにbzrとかあるんだし。

0361デフォルトの名無しさん

2009/07/07(火) 14:17:31

>>357
Python-dev で、Unicodeにデコードできないファイル名どーするよ？という話題に
なったときに、hgの開発者が「文字列（=Unicode）ではなくバイト列でのファイルシステム
へのアクセスは必要だから、例外的な回りくどい方法にしないでくれ」みたいな
事を言ってた。
mercurialはPython3kになってもきっとファイル名はバイト列のまま。

0362デフォルトの名無しさん

2009/07/07(火) 14:59:14

githubでもbzrが使えればbzr使うんだが

0363デフォルトの名無しさん

2009/07/07(火) 15:01:31

githubよりlaunchpadの高機能な気がするが、どうしてもgithubでbzrを使いたいならbzr-git使えば良くね?

0364デフォルトの名無しさん

2009/07/07(火) 17:07:05

>>363
bzr-git は、pull と gitプロトコルでのserveしか対応してないからムリポ。
stacked branch とか bzr の良いところを利用するにはやっぱり launchpad。
wikiが無いのは…

0365デフォルトの名無しさん

2009/07/07(火) 17:43:58

素直にgit使った方がいいんじゃない？
使ってりゃ慣れるよ。
余計なことしないからUTF-8環境なら逆に問題は少ないし。

0366デフォルトの名無しさん

2009/07/07(火) 20:34:32

> 使ってりゃ慣れるよ。
いまひとつ信じ難い
コマンドの名前はともかくとして、本当にあのオプション設計に慣れるのか？

0367デフォルトの名無しさん

2009/07/07(火) 23:03:22

>>361
WindowsとUnix系の違いってのは理解してもらえないもんなのかねぇ。

0368デフォルトの名無しさん

2009/07/07(火) 23:13:31

今の世の中、Windows は避けて通れないのに、
なぜかおざなりにされるんだよね。

0369デフォルトの名無しさん

2009/07/07(火) 23:30:58

>>368
逆に考えるんだ

0370デフォルトの名無しさん

2009/07/07(火) 23:43:48

憎まれっ子世に憚ると申しまして。

0371デフォルトの名無しさん

2009/07/08(水) 00:09:44

>>366
道具に人間の手の方を合わせるのはバカげているという考えには同意する。
ただ質問の答えなら YES だ。
(それにgitがそれほどバカげた道具だとも思わない。名前以外は。)

0372デフォルトの名無しさん

2009/07/08(水) 00:23:55

>>367-368
Windows対応もマルチバイトファイル名も開発者が(コミッタ？)その環境で使ってないから、につきる。
何が酔狂に好き好んで、自分の使ってないマシンとか環境の面倒も見なけりゃ意見のだ？
金貰ってやってるような仕事じゃないんだぜ？

よくあるだろ、Windowsのフリーソフトのフォーラム覗いたら、
「Mac版も作ってください」「知るかボケ(やんわりと)」って受け答え

0373372

2009/07/08(水) 00:25:39

俺はWindowsを非難しているわけじゃないぞ。おれ自身はむしろ、Windowsもクライアントで、Linuxも鯖で使ってる方だからな。

0374デフォルトの名無しさん

2009/07/08(水) 00:38:00

別にcp932だけが悪い訳じゃなくて、UTF-8でも正規化の問題とか、Mac OS Xで
あったりするじゃん。
svnを置き換えるような、クロスプラットフォームで汎用のバージョン管理ソフトには、
やっぱり環境依存なファイル名の扱いを吸収してくれる機能が必要なんだよな。

Linuxだけでファイル名のエンコーディングも全nodeでそろえられるような限定された
環境か、Windowsにはcygwin入っているのが当たり前っていう人のコミュニティの中で
しかgitはムリだと思う。

0375デフォルトの名無しさん

2009/07/08(水) 00:46:46

>>372
rubyのmatzがそれでMacもらったりしてたよな
実際にMacの対応が良くなったかどうかは知らんが

0376デフォルトの名無しさん

2009/07/08(水) 02:26:10

やったことないけどGitでCP932にそろえればいいんじゃね？
UTF-8はうまくいってる気がする。

0377デフォルトの名無しさん

2009/07/08(水) 02:51:58

>>376
UNIX側でCP932をデフォルトエンコーディングにすると確実に死ねると思うのだが。
何処に行ってもUTF-8にするのが無難な解。
# とは言え、そっちはそっちでNFC vs NFDとかWAVE DASH問題とか……orz

0378デフォルトの名無しさん

2009/07/08(水) 08:35:31

Unix（というかPOSIX）ではファイル名は単なるバイナリ列なんだよね
'\0' と '/' が特別扱いされるだけで

この意味では hg/git のやり方にも一理ある

0379デフォルトの名無しさん

2009/07/08(水) 12:17:29

>>377
＞UNIX側でCP932をデフォルトエンコーディングにすると確実に死ねると思うのだが。
滅多にやらないけど、ロケールSJISってなんか問題あるっけ？

＞何処に行ってもUTF-8にするのが無難な解。
そりゃそうなんだけど、Windowsの人が日本語ファイル名ダメだって言うから。

0380デフォルトの名無しさん

2009/07/08(水) 13:05:00

>>378
＞Unix（というかPOSIX）ではファイル名は単なるバイナリ列
それはファイルシステムの話だろ。
シェルやアプリケーションがどのように
扱うかはまた別の話。

0381デフォルトの名無しさん

2009/07/08(水) 13:40:11

>>379
2バイト目が0x5c
>>380
posix api の話
>>378
gitにとってはWindowsは公式サポート外だから別に良いけど、
hgはWindowsも公式サポートされている。

0382デフォルトの名無しさん

2009/07/08(水) 16:27:52

NEWSはShift-JISがデフォだったけどな

0383デフォルトの名無しさん

2009/07/08(水) 16:29:21

昔のHP-UXもShift-JIS。今は知らない。

0384デフォルトの名無しさん

2009/07/08(水) 17:05:45

またcygwinはwindowsじゃないというトンデモか

0385デフォルトの名無しさん

2009/07/08(水) 20:07:56

>>378
Unix系は問題ないんだよ。　
Windowsでは文字列として扱ってもらわないと困るって話。

Cygwinは、UTF-8 Cygwinが標準になってくれれば…。

0386デフォルトの名無しさん

2009/07/08(水) 21:49:47

Windowsも使わないし日本語ファイル名も使わないわしにとっては別にどうでもいいなと思った

0387デフォルトの名無しさん

2009/07/08(水) 23:26:23

>>361
デフォルトはそれでもいいから、extensionとかで簡単にbzr的な扱いにもかえ
られるとうれしいんだけどな

0388デフォルトの名無しさん

2009/07/09(木) 01:49:07

>>385
Cygwin-1.7入れてLANG=ja_JP.UTF-8を設定すればおk。
日本語ファイルだらけのワーキングコピーでsvn updateしても無問題。
6月正式リリース予定だったのに、まだMLでproblemだのissueだのPATCHだののSubjectなメールが飛び交ってるが……。

0389デフォルトの名無しさん

2009/07/09(木) 01:55:36

>>379
全てのコマンドがそれに対応していれば問題ない。>>382-383はそういう環境だな。
しかし、コマンドラインやファイル名を単なるバイト列と思ってるコマンドが1つでもあると、そのコマンドを使った時点で破綻する可能性が出てくる。

0390デフォルトの名無しさん

2009/07/09(木) 03:19:48

ここは間をとって、バイト列とエンコーディングのペアで保存すればいいんじゃね？

ruby の文字列がそんな感じだったような。

0391デフォルトの名無しさん

2009/07/09(木) 09:35:35

>>390
改行で1バイト削るためにLFにしちゃうような人種がそんな無駄をするはずがない気が・・・

0392デフォルトの名無しさん

2009/07/09(木) 09:52:15

>>391
改行を LF にするのは当然で、２バイト以上使うのがただの無駄だろ。
それに日本語について考えれば、 UTF-8 で統一するのに比べて Shift_JIS や EUC-JP を
使ったほうが、容量的にはむしろ節約になる。

エンコーディングとペアで保存する場合の問題は、デコード時の処理負荷のほうでしょ。

0393デフォルトの名無しさん

2009/07/09(木) 14:13:45

リポジトリに何でも入れられるようにして出力側で変換するよりも、
リポジトリに突っ込むときに正規化したほうが、いろいろな環境間で
データをやりとりするプログラムにとっては正しいデザイン。

0394デフォルトの名無しさん

2009/07/09(木) 14:15:51

現にUTF-8 で統一してるSubversionにケチ付けてる環境の人って居るの？

0395デフォルトの名無しさん

2009/07/09(木) 14:31:26

>>393
じゃ、おまえはこれから英語しかしゃべるな

0396デフォルトの名無しさん

2009/07/09(木) 14:36:53

>>393
正しいなんて言うのはどうかしてる。
そんな機能は後回しになるのが普通だろ。

0397デフォルトの名無しさん

2009/07/09(木) 15:03:12

>>394 OSXとWindowsで、濁点がついている文字が入っていたりするとうまく動作しない。(NFD問題)

0398デフォルトの名無しさん

2009/07/09(木) 15:04:31

>>397
ファイルシステムで吸収すべき問題なのか、
アプリでがんばるべきか、前者な気はする。

0399デフォルトの名無しさん

2009/07/09(木) 15:12:38

>>397
それも、バージョン管理システムがどうにかするべき問題だよな。
リポジトリに入れるときにはどれかの正規化をしておいて、取り出すときに
その環境の慣習に沿った形式に切り替えればいい。

0400デフォルトの名無しさん

2009/07/09(木) 16:14:00

>>397-399
こういうのがある
http://d.hatena.ne.jp/fujisan3776/20081231/1230700127
本家には取り込まれてないみたいだけど

0401デフォルトの名無しさん

2009/07/09(木) 16:51:22

>>386
まあ、作ってる側もこういう感じなんだろうな。

0402デフォルトの名無しさん

2009/07/10(金) 13:02:23

>>401 >>386
まさにそのとおりだな・・・

直すにはマルチバイト件のやつらが、でかい声を上げて手を上げていかなきゃならない。

Subversionのときは、どうだったけ？TortoiseSVNがちゃんと日本語扱えるようになるまで、
けっこう時間かかった覚えがあったけど。大体2,3年くらい科方と簿絵がある

0403デフォルトの名無しさん

2009/07/10(金) 14:11:07

しかしパッチも受け付けない姿勢には共感しかねる。

0404デフォルトの名無しさん

2009/07/10(金) 20:05:17

パッチを受け入れるのって面倒だぞ。
対応だけで手一杯になる。

0405デフォルトの名無しさん

2009/07/10(金) 20:14:05

だからGitにしろと(ﾏﾃ

0406デフォルトの名無しさん

2009/07/10(金) 23:13:43

今更ファイル名の取り扱いを変更したら互換性が崩壊するから十中八九無理だろうよ

0407デフォルトの名無しさん

2009/07/10(金) 23:16:55

cygwin上のgitも速くなったから実際のところ悪く無い。
GUIがgit.exeを呼び出す形で分離されてるから locale の問題ではむしろ
良い方に働いてる。

0408デフォルトの名無しさん

2009/07/11(土) 07:40:05

TortoiseHg 0.8 だが、win32mbcsを設定したとたん
コミット等まともに動かなくなるようなのだが。
以前はそんなこと無かったのに。

0409デフォルトの名無しさん

2009/07/11(土) 09:40:19

>>408
誰かが壊したっぽい。

0410デフォルトの名無しさん

2009/07/11(土) 09:41:36

win32mbcsを作ったひとが直してくれてるから、次のリリースでは大丈夫だろう
ttp://groups.google.com/group/mercurial-ja/browse_thread/thread/59c4fe5b7409e509

0411デフォルトの名無しさん

2009/07/11(土) 15:58:24

マルチバイトファイル名公式非サポート、
これでWindowsで普及させようなんてアホすぎる・・・

0412デフォルトの名無しさん

2009/07/11(土) 17:10:21

win32mbcsは公式コンテンツですよ

サポートが弱いのはその通りだと思うけど
だからって妄想はほどほどに

0413デフォルトの名無しさん

2009/07/12(日) 02:18:36

>>412
公式？ｗ

0414デフォルトの名無しさん

2009/07/13(月) 17:16:49

Vista SP2 上で cygwin の最新 git 1.6.1.2 を使っています。

.gitconfig に git status を git st で alias 登録しました。

プロジェクトの toplevel では git st で正常に動くのですが、
下の階層のディレクトリに降りて git st すると
全ファイルが modified: とだーっと表示されます。

なので今は git status を書いたバッチファイルを使っているのですが、
解決策をご存知の方はいませんか？

0415デフォルトの名無しさん

2009/07/14(火) 00:35:35

>>414
gitスレでやれ

0416デフォルトの名無しさん

2009/07/14(火) 08:34:48

>>415
Gitスレでこっち誘導されてる。
あっちはLinux板だからCygwinならこっちのほうが知ってる人いるかもね。

0417414

2009/07/14(火) 10:03:20

>>415-416
すみません。。。そして、ありがとうございます。
同じ状態の人はいないのでしょうか。

0418デフォルトの名無しさん

2009/07/15(水) 12:31:48

>>414
再現しない
環境：Vista SP2, cygwin (UTF-8DLL) , git version 1.6.1.2

最低限再現するgitリポジトリを用意して、githubにでもうｐれ

0419デフォルトの名無しさん

2009/07/16(木) 01:23:14

質問なんですが mercurial で commit 時にある特定のファイルにその commit 時の
hash 値を自動で埋め込むってことをしたいのですができますかね。

[extensions]
hgext.keyword =
[keyword]
* =

とかして、
$Revision$ を埋め込んでるんですけど、どうやらそのファイルが
更新されたときしかリビジョン番号の更新をしてくれないみたいで
困ってます。

0420デフォルトの名無しさん

2009/07/16(木) 08:48:05

>>419
自分の体重を計るときにその計測結果の1/10の重さのおもりを持って
計測できるか？

0421デフォルトの名無しさん

2009/07/16(木) 18:59:05

>>420
わかりにくいたとえ。

0422デフォルトの名無しさん

2009/07/16(木) 19:29:25

>>419
後処理でそれをやってくれるスクリプトを書かないとムリじゃね？

0423デフォルトの名無しさん

2009/07/16(木) 20:20:21

>>419
[hooks]
pretxncommit = コマンド名

とすることで、新しいリビジョンをコミットする寸前にコマンドを実行することができますので
そこで埋め込むとよいと思います。
新しいリビジョンのハッシュ値は、環境変数 HG_NODE に格納されて渡されます。

参照：Chapter 10. Handling repository events with hooks
http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:pretxncommit

0424デフォルトの名無しさん

2009/07/16(木) 22:26:45

>>423
どうもありがとう！！
まだ試してないですけど、フック使うって手法で
がんばってみます。

0425420

2009/07/17(金) 00:55:21

>>421 うん、ごめん。 >>423-424 見て反省してる。

>>423-424
ムリ。ハッシュ値ってのは、コミットする内容を元に計算しているから、
ハッシュ値をコミットする内容に含めるとハッシュ値が変わってしまう。

pretxncommit は、コミットする内容が確定してリビジョンまで決まった後の
コマンドだから、その段階でファイルを弄ってもコミットには反映されない。

0426デフォルトの名無しさん

2009/07/17(金) 10:07:39

たぶん、ハッシュ値を使って何を実現したいかを説明した方がいい気がする。
バイナリかリリースするソースにハッシュ値を埋め込んでおきたいのかな、
という気はするけど。

0427デフォルトの名無しさん

2009/07/17(金) 12:25:58

>>419
ファイルが更新されないとリビジョンも更新されないんだから当たり前だろwww

0428デフォルトの名無しさん

2009/07/17(金) 14:14:40

>>427
CVSやSVNならそうなんだけどね。
ttp://hgbook.red-bean.com/read/behind-the-scenes.html
hgリビジョン番号ってfigure4.2でいうところのchangelogのrevidじゃないのかなぁ。

0429デフォルトの名無しさん

2009/07/17(金) 14:42:38

hg tagしたら自動生成されたコミットログが日本語になっとる。

0430デフォルトの名無しさん

2009/07/17(金) 17:11:09

>>428
それはリポジトリのリビジョンでファイルのリビジョンじゃねーだろwww

0431デフォルトの名無しさん

2009/07/17(金) 18:11:23

>>430
それはそうだが、
hgではファイルのリビジョンを知る方法はないよ。
hg debugindexをつかえば、一応見られるが。

0432デフォルトの名無しさん

2009/07/17(金) 18:49:34

>>431
logで見れるだろwww
debugindexってまだあるの？

0433デフォルトの名無しさん

2009/07/17(金) 19:01:26

hg tip ファイル名
で見れない？

0434433

2009/07/17(金) 19:02:18

すいません、
hg parent ファイル名
でした。

0435デフォルトの名無しさん

2009/07/17(金) 20:31:51

>>434
出てくるのは00changelog.iのリビジョン番号だし、
ちゃんとchangeset:って書いてあるし。

0436デフォルトの名無しさん

2009/07/17(金) 20:40:26

>>435
すまん、問題を取り違えてたわ。

0437デフォルトの名無しさん

2009/07/19(日) 19:31:01

今まで一つのリポジトリを研究室と自宅で操作してて、
コミットし忘れが結構な頻度で発生して面倒だったんだけど、
OSの起動時にフックして自動的にpull/pushしてくれるようなソフトない？
使ってるVCSはbazaarだけど、これがあるならgitだろうがmercurialだろうが移行するぜ。

なかったら言い出しっぺの法則で暇を見て作ろうと思います。
ちなみに皆さんはどうやって同様の問題を解決してますか？

0438デフォルトの名無しさん

2009/07/19(日) 19:36:49

>>437
リモートログインしてpushすればいいんじゃね?

0439デフォルトの名無しさん

2009/07/19(日) 19:50:48

＞OSの起動時にフックして自動的にpull/pushしてくれるようなソフトない？
Windowsでしょ？バッチファイルをスタートアップに入れておけばいいんじゃね？

0440437

2009/07/19(日) 20:08:47

>>438
出先のPCは電源を落としてるので、リモートログインはできないのです。
もっとも研究室のPCなので外からログインできるかは微妙ですが
（VPN使う手もありますが、なにかとまずそうなので・・・）

>>439
主にubuntu使ってますが、windowsも開発で使わなければならないときもあるんで、まあ両方ですね。
linuxでもdaemonとかいう、いわばサービスにファイルを登録するだけで起動/終了時にスクリプトを走らせることができます。
ただ、それだけでは終了時のpushができなかったり、スタンバイやハイバーネート、スリープなどに対応できないと思いますので、
結局フックやらを考えないといけないとは思いますが・・・

現在考えてるソフトウェアの構成はこんな感じです。

・VCSをpull/pushするスクリプト（おそらくRubyかPython)
・OSに上のスクリプトを走らせるためのソフトウェア(Windowsならサービス、Linuxならdaemon?)

最初はbazaarとlinuxで試してみて、それが出来次第他のVCSやWindowsもできたらいいなと思っています。

0441デフォルトの名無しさん

2009/07/19(日) 20:25:00

.bash_profileと.bash_logoutじゃいけない理由でもあるの?
まぁ、logoutする習慣がないなら泣け。

# しかし、本質的にはその辺りは自動にするより習慣付けるのが一番ではある。

0442デフォルトの名無しさん

2009/07/19(日) 20:28:07

自宅のPCにリモートで入ればいいじゃん

0443437

2009/07/19(日) 20:30:25

>>441
まあその辺の手も考えなくはなかったのですが、
普段もっぱらscreenを使用してるので.bash_logoutスクリプトが自動的に呼ばれないことと、
複数のリポジトリを更新してほしいときなどに面倒なので、それならいっそリポジトリのパスを含めた設定ファイルと、
それをpull/pushする簡単なスクリプトを書こうと思ったわけです。

> # しかし、本質的にはその辺りは自動にするより習慣付けるのが一番ではある。
まあおっしゃる通りなんですが、分散型を使ってるとcommitはともかくpushは忘れがちで・・・。

0444デフォルトの名無しさん

2009/07/19(日) 21:03:22

馬鹿じゃない?

0445デフォルトの名無しさん

2009/07/19(日) 21:06:46

>>443
screen使用とログアウトしないこととの関連が判らんが、
「複数のリポジトリを更新して欲しいとき」という要求が発生するタイミングがあるなら
まさしくその瞬間に自分でpushするスクリプトを起動すればよいのでは?
pushを忘れるのが嫌なら、例えばコンパイル時にpushするようにMakefileを書けばいいだけだし、
やっぱり何をしたいのか判らない。

0446デフォルトの名無しさん

2009/07/19(日) 21:16:55

cronで定期的にhg outgoingみたいなので未pushの一覧を出力してメールで飛ばせ。

0447デフォルトの名無しさん

2009/07/19(日) 21:19:22

>>443
pushを忘れがちというのには同意。
pushされた側でupdateをわすれがちなのもあるよね。

0448437

2009/07/19(日) 21:46:26

>>445
> screen使用とログアウトしないこととの関連が判らんが、
screenがバックグラウンドでシェルの状態を保持するために、ターミナルを閉じても.bash_logoutが呼ばれないのです。
それに、OpenOfficeのファイルなどをGUIから編集するときなどでもpush(commit)してほしいので、
シェル起動が前提の仕組みはちょっと・・・。

> pushを忘れるのが嫌なら、例えばコンパイル時にpushするようにMakefileを書けばいいだけだし、
ソースコード以外のファイルも同期したいので、Makefileに書くのは難しいかと思います。

> やっぱり何をしたいのか判らない。
すいません、きちんと書いたつもりだったのですが、へたくそな文章でいまいちうまく伝わってなかったようです。
要は、登録された作業コピーを、OS起動時にupdate/pull、終了時にcommit/pullしたいのです。
それでいちいち分かりきった作業をせずに済みますし、なによりupdate(pull)しなければいけない、と考える必要がなくなります。

>>446
なるほど、それならメールをチェックしていればどれをpushしていないのか分かりますね。
でも、例えば長時間起動してcommitしながらOS終了時にpullするような使い方だと、
チェック時に毎回メールするようだとメールがどんどん増えていってやがて見なくなるでしょうし、
一回だけだと逆に終了時に忘れてしまうような気がします。

>>447
自分もうっかりものなのでよく起こしてしまいます。
特に自分のホームディレクトリの同期などはコンフリクトが起こらないことが明確なので、
自動的にpull/pushしてくれればいちいち気にせず使えて便利だと思ったわけです。

0449437

2009/07/19(日) 21:49:57

>>448
すいません、一部言葉足らずな部分があったので修正させてください。

> >>446
> なるほど、それならメールをチェックしていればどれをpushしていないのか分かりますね。
> でも、例えば長時間起動してcommitしながらOS終了時にpullするような使い方だと、
> チェック時に毎回メールするようだとメールがどんどん増えていってやがて見なくなるでしょうし、
> 一回だけだと逆に終了時に忘れてしまうような気がします。

でも、例えば長時間"PCを"起動してcommitしながらOS終了時にpullするような使い方だと、
"cronの"チェック時に毎回メールするようだとメールがどんどん増えていってやがて見なくなるでしょうし、
"差異を発見した一回目"だけだと逆に終了時に忘れてしまうような気がします。

0450デフォルトの名無しさん

2009/07/19(日) 21:54:50

>>449
cronでpushしちゃえよ。人間になれない人にはぴったりだ。

0451デフォルトの名無しさん

2009/07/19(日) 22:00:54

DropBox使えば？

0452デフォルトの名無しさん

2009/07/19(日) 22:01:47

>>450
＞人間になれない人
???

0453437

2009/07/19(日) 22:11:52

>>451
まさにそのDropBox的な使い方をしたいのですが、
DropBoxだと容量に制限があったり、履歴管理に柔軟性がなかったりするので、
できればVCSを使って同様の機能を実現したいのです。

0454デフォルトの名無しさん

2009/07/19(日) 22:22:56

間抜けってことか。

0455デフォルトの名無しさん

2009/07/19(日) 23:12:37

>>437
bzr なら branch じゃなくて checkout したら良いじゃん。

0456デフォルトの名無しさん

2009/07/20(月) 01:09:08

分散型使うのやめればいい

0457デフォルトの名無しさん

2009/07/20(月) 01:25:31

そもそも437の使い方で、push忘れは大きな問題になるのか？
逐一pushしなくても問題がないのなら、思い出した時にだけpushすればいいと思うんだが

0458デフォルトの名無しさん

2009/07/20(月) 06:58:39

USBメモリにリポジトリをおけば解決?

0459デフォルトの名無しさん

2009/07/20(月) 08:13:16

>>458
大丈夫、>437ならそれでも忘れてくれる。

私はそうしているけどね。

0460437

2009/07/20(月) 09:16:21

>>455
>>456
その手は全然考えてませんでした。
ですが、集中型を使ってもやっぱりcommitを忘れると同様のことが起きそうですね。

>>457
研究室で編集したものをpushし忘れると、
自宅に帰って続きをしようとしたときにせっかく変更したファイルを得られなくなるんです。
実際にはそういったことが何度もあったわけではないのですが、
分かりきった作業に毎回毎回気を配るのは面倒だと思った次第で、それなら自動化できないかと思いました。

>>458
すいません、ローカルリポジトリ/中央リポジトリどっちをUSBメモリに置いたときの話でしょうか？

0461デフォルトの名無しさん

2009/07/20(月) 09:30:56

>>460
さすがにcommitを忘れるようなら、集中だろうと分散だろうと自動pushしようとどうにもならんよ
まさか任意のタイミング（シャットダウン時）で自動commitするわけにもいかんだろう

0462デフォルトの名無しさん

2009/07/20(月) 10:17:29

たしかに commit 忘れも救うってのはダメだな。
何のための commit なのかわからなくなる。

必要なのは VCS+α じゃなくて自動ファイル同期機構だろう。

0463デフォルトの名無しさん

2009/07/20(月) 10:52:57

>>460
自宅で作業するときに pull すりゃいいんじゃねーの？
push に気を使うよりか作業前に pull する方が習慣として
楽なんじゃないかと思うんだが。

0464デフォルトの名無しさん

2009/07/20(月) 14:15:37

>>463
そもそもpushされてないのに、どうやってpullしろと。

スケジュールかtodoでpushアラート出して、自分を誘導して実行していくのが確実な気がする。
アラート無視はもうやる気がないとしか。

0465デフォルトの名無しさん

2009/07/20(月) 14:17:39

素直に集中型のVCS使ったほうがいいんじゃね？

0466デフォルトの名無しさん

2009/07/20(月) 14:38:25

ってか、gfsとかcLVMとかを使って作業コピーや分散リポジトリのあるディレクトリを
丸ごとどこか外に追い出せば済む話みたいに聞こえるんだが。
SCMとか以前の問題だろ。

0467デフォルトの名無しさん

2009/07/20(月) 15:49:16

コーディング用のノートパソコンを一台用意する
commit忘れちゃう437を救うにはこれしかない

0468デフォルトの名無しさん

2009/07/20(月) 16:16:26

いっそのことコード書くのも忘れちゃうというのはどうか

0469デフォルトの名無しさん

2009/07/20(月) 18:09:16

>>460
VisualStudioとかの統合環境にプラグイン入れれば、閉じるときに更新されてれば
commitするか聞いてくれるよ。

0470デフォルトの名無しさん

2009/07/20(月) 19:20:21

>>460
研究室と自宅で同じ作業するなら中央もローカルも USB 上でやればいいだろ

0471デフォルトの名無しさん

2009/07/20(月) 20:13:04

>>465
問題はコミットし忘れなんだから、集中型だろうがだめだろ

0472デフォルトの名無しさん

2009/07/21(火) 12:24:31

>>469
437なら閉じずにハイバネートするだろうな

0473デフォルトの名無しさん

2009/07/21(火) 13:19:03

SCMを使わずにNFS/Sambaで同じディレクトリを共有。
開発もその上でやれば、保存した瞬間に同期される。

0474デフォルトの名無しさん

2009/07/21(火) 13:49:07

>>473
437ならファイルを保存し忘れる可能性もある

0475デフォルトの名無しさん

2009/07/21(火) 14:04:54

437なら自分が何者で、どこに帰って良いのか忘れてしまう可能性もある

0476デフォルトの名無しさん

2009/07/21(火) 14:31:25

Launchpad is now fully open source
http://beuno.com.ar/archives/144

0477デフォルトの名無しさん

2009/07/21(火) 23:23:36

437のことはもう許してやれよｗ

0478デフォルトの名無しさん

2009/07/22(水) 10:17:38

許してやるから出てこいよ

0479デフォルトの名無しさん

2009/07/22(水) 10:31:18

Mercurialのextdiffでフルパス送る方法ないですか？

0480デフォルトの名無しさん

2009/07/22(水) 12:33:40

>>479
extdiffはテンポラリにcdしてからファイル名のみを渡します。
pwdを拾うラッパーを書けばよいのではないでしょうか。

0481479

2009/07/22(水) 14:07:58

>>480
ありがとうございます。やっぱそれしかないんですね。
もうPython勉強して自分でパッチ書いた方がいいかな……。

0482デフォルトの名無しさん

2009/07/23(木) 12:05:42

/home 以下を全部差分バックアップするのにお勧めなのはどれになるのでしょうか
そういう使い方するものではないのでしょうか？

0483デフォルトの名無しさん

2009/07/23(木) 12:09:37

>>482
あくまで俺の感想だけど、SCMはバックアップ用途には使いにくいと思う。
リポジトリも増える一方だし。

個人的にはバックアップではrdiff-backupを使ってる。
rsyncに履歴をつけたようなやつ。

0484デフォルトの名無しさん

2009/07/23(木) 20:34:08

Canonical、LaunchpadのソースコードをAGPL 3で公開 - スラッシュドット・ジャパン
" Ubuntuの開発でも知られるCanonicalが、ソフトウェア開発プロジェクト管理システム「Launchpad」のソースコードをGNU Affero General Public License（AGPL）v3で公開した（SourceForge.JP Magazineの記事、Launchpad development Wiki）。

Launchpadはバージョン管理ツールBazaarをメインに据えたソフトウェア開発支援システムで、バグトラッカーや翻訳支援ツール等の機能を備えている。

なお、今のところLaunchpadはUbuntu 8.04～9.04でのみビルド可能とのこと（dev.launchpad.netのインストール方法解説ページ）。"
http://slashdot.jp/it/article.pl?sid=09/07/23/0535203

0485デフォルトの名無しさん

2009/07/24(金) 06:17:42

おっ、ついにきたのね。さっそく試してみるか。

0486デフォルトの名無しさん

2009/07/24(金) 06:25:36

なんでウブンツでしかビルドできねーんだ

0487デフォルトの名無しさん

2009/07/24(金) 10:18:08

これまでCanonicalが使って来た分に関してはそれで十分なわけで。

0488デフォルトの名無しさん

2009/07/24(金) 10:21:33

Mercurial 1.3.1出たね
win32mbcsがこけてたのが直ってる

0489デフォルトの名無しさん

2009/07/24(金) 10:37:23

なにィ、昨日サーバー設定してて、1.3 入れたばかりなのに。
まあ蓄積用のサーバーだから細かいことはいいんだけど。

0490デフォルトの名無しさん

2009/07/24(金) 10:39:48

AGPL に注意

0491デフォルトの名無しさん

2009/07/24(金) 18:35:35

>>489
わかちこ、わかちこ

0492デフォルトの名無しさん

2009/07/25(土) 03:20:53

昨日1.3落としたけど
バージョン上げるのﾏﾝﾄﾞｸｾ('A｀)で放置した俺は勝ち組ｗ

0493デフォルトの名無しさん

2009/07/25(土) 03:49:14

TortoiseHg0.8.0入れたらcommitのUIとか立ち上がらない…。
みんな使えてるの？

0494デフォルトの名無しさん

2009/07/25(土) 08:44:42

>>493
亀hg0.8はhg1.3内蔵で、
hg1.3はwin32mbcsが壊れてるのでそうなる。
有効にしてない？

0495デフォルトの名無しさん

2009/07/25(土) 08:54:39

TortoiseHg 0.8.1(with Mercurial 1.3.1)
ってもうできてるんじゃん。
ttp://bitbucket.org/tortoisehg/stable/downloads/

0496デフォルトの名無しさん

2009/07/25(土) 14:51:07

hgsccも新しいの出てた。
てっきり最初のバージョンだけで放置してると思っていたが
5月にも更新されてたんだな。

0497デフォルトの名無しさん

2009/07/25(土) 21:58:15

>>494
有効になってた。
ありがとう！

hg0.8.1だと、win32mbcsでエラーはないが、ダメ文字はコミットできないみたいね…。

0498デフォルトの名無しさん

2009/07/30(木) 20:34:23

Mercurial、エディタの制御まともにできないの直ってる？
コミットメッセージ再編集不可なのはどうせ直ってないんだろうなあ
まともな分散型が使えるようになるまであと何十年かかるかな

0499デフォルトの名無しさん

2009/07/30(木) 22:55:38

レポートされなかったバグはないのと同じ

0500デフォルトの名無しさん

2009/07/30(木) 22:56:32

0501デフォルトの名無しさん

2009/07/31(金) 08:35:20

ちょっと試すぐらいの気概もないならやめちゃえば。

0502デフォルトの名無しさん

2009/07/31(金) 21:03:37

darcsで日本語ファイル名は使えますか？

0503デフォルトの名無しさん

2009/08/03(月) 05:02:18

単発の設定ファイルなんかをいちいちリポジトリを作らずに
スナップショットとるようなツールってないのかな。
ボリュームシャドーコピーやTortoiseSVNのような使い勝手で
スナップショットとるタイミングはユーザーが明示できるようなもの。

ちょっとしたINIファイルなんかを念のためバージョン管理下に置いておきたいんだけど
かといって従来型のはちょっと面倒と言う時に気軽に使いたい。

0504デフォルトの名無しさん

2009/08/03(月) 08:51:24

設定ファイルをシンボリックリンクで一箇所に集める。

0505デフォルトの名無しさん

2009/08/03(月) 10:03:47

hg, bzr,git
ソースを読みやすいのはどれ？

0506デフォルトの名無しさん

2009/08/03(月) 10:14:15

>>503
UNIX ならそういう用途だと自分はいまだに RCS 使っちゃうなあ。
/etc の下のファイルいじるときに、あまり自信のないときには ci してから編集したり。

0507デフォルトの名無しさん

2009/08/03(月) 13:31:28

>>506
俺もRCS使う。
同じ用途でMercurialも使うけど、RCSほどインストールされてない。

0508デフォルトの名無しさん

2009/08/03(月) 15:15:45

git 使うようになった

0509デフォルトの名無しさん

2009/08/03(月) 16:26:35

etckeeper使うときのメリットってある？

0510デフォルトの名無しさん

2009/08/06(木) 02:33:10

リポジトリをUSBフラッシュメモリに入れられて、
それをWindowsからでもLinuxからでも使えるような
バージョン管理システムってあるでしょうか？

機能だけならDropboxでも十分なのですが、ネットワークが
ないところでも使えてデータはローカルに置いておきたいです。

0511デフォルトの名無しさん

2009/08/06(木) 02:34:09

svn

0512デフォルトの名無しさん

2009/08/06(木) 02:49:35

>>510
分散型なら普通にできるんじゃない？

0513デフォルトの名無しさん

2009/08/06(木) 10:56:44

>>511
Subversionはリポジトリ内のロックファイルやフックスクリプトの改行コードが
OSに依存しているみたいだから、そのまま使えないかも。

0514デフォルトの名無しさん

2009/08/06(木) 15:09:38

他のプログラムが頻繁によばれるような使い方するなら
cで書かれたgitが一番速度も速いし安心なのか

0515510

2009/08/06(木) 23:40:03

svnのリポジトリってOSに依存してるのかと思ってましたけどFSFSなら
大丈夫そうですね。USBメモリ上のリポジトリでWindowsとLinuxの両方から
co, ciしてみましたがちゃんと動いているようです。

しばらくバックアップ取りながらこれで使ってみます。
ちなみにUSBメモリはFAT32、WindowsではCygwinを使っています。

>>512
全然詳しくないですけど、分散型でもリポジトリのデータは
OSに依存してるものとかあるんじゃないですかね？

>>513
今回はロックもフックも使わないので大丈夫そうです。
ただ、どこかで問題が起きるのではと心配しています…。

0516デフォルトの名無しさん

2009/08/07(金) 07:37:54

リポジトリがOS依存ってｗ
そんなの使い物にならなくないか？

ていうかあるの？
Bzr, git, hg, SVNを平行して使ってるんだけど、こええな

0517デフォルトの名無しさん

2009/08/07(金) 08:39:45

分散型だからといってOS非依存が条件なわけでもないだろ
クライアントやプロトコルがOS依存って話でもないのに何を怖がってるんだ？

0518デフォルトの名無しさん

2009/08/07(金) 10:26:34

>>515
SubversionでもBazzarでもUSBにリポジトリを置いているけど問題ないよ。

0519デフォルトの名無しさん

2009/08/07(金) 11:51:42

>>517
USBの中に入ってるレポジトリがOS依存だったら大問題だろ

0520519

2009/08/07(金) 12:12:22

補足
USBメモリの中に入ってるレポジトリが、たとえばWindowsに依存していたら
LinuxからそのUSBメモリを開いたとき、レポジトリの中身が見られなくなる、という意味ね

0521デフォルトの名無しさん

2009/08/07(金) 12:15:36

改行コードとかは属性付けておけば良いだけだし
フックスクリプトなんてWin用とLinux用でも作っておけば良いじゃん

0522デフォルトの名無しさん

2009/08/07(金) 13:28:05

>>519
アホ？

0523デフォルトの名無しさん

2009/08/07(金) 13:30:01

>>519
リトルインディアン嘘つかない

0524デフォルトの名無しさん

2009/08/07(金) 13:34:47

>>520
そのことと>>517に何の関係があるんだ？

0525デフォルトの名無しさん

2009/08/07(金) 16:08:08

分散型であることとリポジトリ自体が異なるOS間で可搬であることは何の関係も無いよね。
リポジトリ自体の物理的な保存場所をOSまたいで持ち運ぶような用途が想定されているかどうかだけ。
物理的な格納の仕方の話だからファイルシステムも関係ある。
分散は関係ない。

0526デフォルトの名無しさん

2009/08/07(金) 17:28:55

なにこれ

0527デフォルトの名無しさん

2009/08/07(金) 18:13:26

ぐだぐだ曖昧論を繰り返すより
510の用途でトラブルが発生するツールを上げた方が有用だろう。
トラブルが出ないものはいくつか挙げられた。

0528デフォルトの名無しさん

2009/08/07(金) 18:19:35

>>510 が好きなのを試してみて、使えたかどうか報告してくれると有難い

0529510

2009/08/07(金) 22:02:05

>>528
515に書いたようにsvnで満足しそうなのでこれでいいかなと思っています。
何か問題が起きたらまた相談に来ます。

0530デフォルトの名無しさん

2009/08/08(土) 04:51:01

>>527
たぶん、ビッグエンディアンのマシンでBDBで作ったSubversionリポジトリをコピーしてリトルエンディアンのマシンに持ってくと壊れると思われ。
そういう特殊ケース以外は結果的に問題ないんじゃね? 根拠はないけど(ぉぃ

0531デフォルトの名無しさん

2009/08/08(土) 11:35:16

>>530
マジで？

DBDはバージョンアップのたびにアップデート必要だったり散々な思い出しかないわｗ
svnのBDBってかなりヤバイイメージ･･･

頼むから、同じ過ちを繰り替えささないで、とは思う

0532デフォルトの名無しさん

2009/08/08(土) 12:58:28

BDBの存在意義がわからない

0533デフォルトの名無しさん

2009/08/08(土) 13:01:32

今じゃFSFS使えば困らないからね…と思ってたがRubyをsvnsyncした時は心が折れかけたｗ
BDBの代わりにSQLite使ったらどうなるんだろうか

0534デフォルトの名無しさん

2009/08/09(日) 20:31:01

svnのバックに汎用のRDBをもってこれないの？

0535デフォルトの名無しさん

2009/08/09(日) 21:06:40

svnのバックエンドにgitってのはあるみたいね

0536デフォルトの名無しさん

2009/08/09(日) 22:23:01

JavaEE5を用いたシステムで
ソースとEAR等のアーカイブ以外に、
クラスもバージョン管理したいって上司が言ってるんですが、
そんなこと普通するのでしょうか・・・
皆さんのご経験をお聞かせ願えますか？

0537デフォルトの名無しさん

2009/08/09(日) 22:35:11

>>536
しない。

ビルドターゲットの違いを心配してるんだろうけど
わざわざ、クラスの管理はしない。
もしするんだとしても、開発用とは分離したレポジトリだな。

0538デフォルトの名無しさん

2009/08/09(日) 22:43:23

>>536
流石にそんな経験はないな。

0539デフォルトの名無しさん

2009/08/09(日) 23:29:53

>>536
むしろ、してはならない類いの一つ。

0540デフォルトの名無しさん

2009/08/10(月) 00:20:33

>>537,538,539
貴重なご経験教えて頂き、皆さんありがとうございます。
何とか上司を説得してみます。

0541デフォルトの名無しさん

2009/08/10(月) 11:08:58

必要最小限の機能しか使わないならcvsでいいのかな

0542デフォルトの名無しさん

2009/08/10(月) 11:22:21

流石にこれから導入ならcvsよりはsvnじゃね？

0543デフォルトの名無しさん

2009/08/10(月) 12:30:51

git だろ

0544デフォルトの名無しさん

2009/08/10(月) 12:41:59

俺もsvnを使う。
cvsはディレクトリの移動に対応していないし
同時にコミットしてもファイルごとに別のリビジョンになるので
他のSCMに慣れた今では気持ち悪い。

0545デフォルトの名無しさん

2009/08/10(月) 12:54:43

>>543
cvsとgitはぜんぜん別物じゃん

0546デフォルトの名無しさん

2009/08/10(月) 12:55:08

LinusがSVNは糞ってゆってた

0547デフォルトの名無しさん

2009/08/10(月) 12:59:26

CVSは論外ともな

0548デフォルトの名無しさん

2009/08/10(月) 13:00:54

mercurial か bazaar だよ

0549デフォルトの名無しさん

2009/08/10(月) 20:23:08

CVS使うぐらいならSVN使った方がいいよなぁ。
上位互換って感じだし。

分散系はどれが主流になるかわからんから
今のところ趣味レベルでいい気はするわ。

0550デフォルトの名無しさん

2009/08/10(月) 20:31:22

今から使うならCVSでなくSVN使うけど、SVNはタグとブランチの扱いが不満。

0551デフォルトの名無しさん

2009/08/10(月) 22:14:22

>>550
svnのタグってコピーだもんね。

0552デフォルトの名無しさん

2009/08/10(月) 22:18:21

>>546-547
Linux Kernelの開発には機能不足でまるで使えないそうな。
まぁそうだろうなとは思う。
あそこまで大規模かつ分散した開発形態なんて、CVSが出た頃には考えもつかなかっただろうし。

0553デフォルトの名無しさん

2009/08/10(月) 22:20:24

>>541
何が必要かによるんじゃない？

用途によってはRCSで充分なこともあれば、gitじゃないと困ることだってある。

0554デフォルトの名無しさん

2009/08/10(月) 23:11:27

>>552
gitの入門を読んだ限りでは、自分や他人の作業について、非同期性を如何に上げるか(如何に妨げず/妨げられず、かつ如何に追随する/させるか)という点を重視してる感じがする。
だから、そういう部分に需要がない場合はgitは使いづらいんじゃなかろうか。

とは言え、新規に立てるなら、コミットの単位がトランザクショナルじゃないCVSは今さらありえないけど。
先日ものすごく久々にCVSを使ったとき、「この差分はどこを起点にしていると説明すればいいのだろう」と一瞬固まったもんな。

0555デフォルトの名無しさん

2009/08/11(火) 00:02:50

CVSに誤解があるようなので弁護すると
コミットするとき関係するディレクトリに書き込みロックをとるのでトランザクションになっている。
CVSで問題なのはトランザクションで更新されたファイルを後から調べる方法が用意されてないところ。

0556デフォルトの名無しさん

2009/08/11(火) 00:49:05

Winで色分けして表示してくれるコマンドラインのdiffってないかな。

0557デフォルトの名無しさん

2009/08/11(火) 03:58:38

>>556
vimdiff

0558デフォルトの名無しさん

2009/08/11(火) 12:36:21

他のメンバーに、ちょっと試したいことがある時とかはすぐブランチ切れって言ってるんだけど、
面倒らしくなかなか切ってくれない。
trunk一本でやろうとしてて、試行が上手く行かなかった結果をコミットしたくない、とか言い出す。
そのわりに、上手く行かなかったのってどんなことやったの？ってレビューするときに、コミットしてないから忘れた、
とか言い出すw

そういうのは、ブランチ切っておいて、間違ったらコミットはするけど、そのブランチは放置しとけばいいって言ってるんだけど
どうしたもんかね。

svnって分散系に比べてブランチきるのがすげー面倒なイメージは確かにある
分散だったら極端な話、cloneするだけでそれでも一応ブランチになるし。

0559デフォルトの名無しさん

2009/08/11(火) 12:38:00

>>556
おれはむしろ、色分け表示してくれるGUIのdiffビューアがほしい…

0560デフォルトの名無しさん

2009/08/11(火) 12:43:28

winmergeじゃ駄目なん

0561デフォルトの名無しさん

2009/08/11(火) 12:52:44

>>558
同感
実装が終わってないといって何週間もコミットしてくれなくて困った
進捗状況がまったく見えないし間違った方向に進んでいるかもしれないし
書きかけのコードをコミットさせる工夫はある?

0562デフォルトの名無しさん

2009/08/11(火) 12:56:58

>>558
Subversion＋MQで使えばいいと思います

0563デフォルトの名無しさん

2009/08/11(火) 13:01:37

安易ブランチ切るなって所もあるけどな

ブランチ切るのめんどくさいって言って言う事聞かないやつには
svkでも他の分散型でも薦めたところでめんどくさくて使ってくれないだろうな

0564558

2009/08/11(火) 13:03:00

> 書きかけのコードをコミットさせる工夫はある?

うちは、そういうのやってないなー。

チケット駆動開発してて、切りのいいところでコミットしてほしんだけど(コミットログでチケットに関連付ければいいし)、
あるメンバーはタスク1個につき、1コミットかもしくは、まとめて数タスクやってコミットとかする
そのメンバーとはプロジェクト一緒じゃないからいいけど、もうちょっとまめにコミットしようぜって言ってるｗ

俺は、なるべくバンバンコミットしてる方だけど。
ただ、切りがよくても動かないコードはさすがにコミットしづらい。それこそ、ブランチなんだろうけどね。

>>558
ちょっと見てみる

0565558

2009/08/11(火) 13:08:44

> ただ、切りがよくても動かないコードはさすがにコミットしづらい。それこそ、ブランチなんだろうけどね。

ごめん、このくだり意味がわからんな。俺も読み直して意味がわからん

>>563
そうそう、面倒くさがってしまうもんだよねー

以前、TortoiseSVN使ってもらってた時も、あるメンバーがなかなかコミットしないようになったから、
なんで？って問いただして後ろから作業見てたら、
OS再インストール時にsshのパスワード入力をある程度省略するpageantの導入してくれてなくてだな
(ちゃんとインスコ方法とか俺社内マニュアルに書いたのによー)
何かことあるごとに、パスワード入力しなくちゃならないのが面倒なようだった。

TortoiseSVNで素のsvn+sshだと、コミットウインドウ開くとか、リスト取得とかログ見るとかコミットするとか、
何かするたびに頻繁にパスワードを聞かれて、俺でもいやになるわｗ

0566デフォルトの名無しさん

2009/08/11(火) 13:09:28

朝一と昼に cron とかで自動的に nightly ブランチに突っ込ませてるよ。
最初、昼だけだったんだけど、
朝一は今日やる作業を戻したい時用に使ってる。

0567デフォルトの名無しさん

2009/08/11(火) 13:10:56

めんどくさがる割にコードレビューには参加してくれるんでしょ
やり方の問題なんじゃね？

ちょっとお試しでのコミットがtagsでやって欲しいけど

0568デフォルトの名無しさん

2009/08/11(火) 13:14:32

>>558
svnはワーキングコピーをリポジトリに直接コピー可能だから、事前にブランチ作らなくても良いのにな。
trunkで作業してて、ブランチにしたくなったらワーキングコピーをブランチにコピー、その後スイッチ。

進捗見せないとか、成果物残ってないやつは寝てるのと同じだから、俺は直ぐクビにしたい。
ソースもドキュメントもSCMで管理されていない状況は許さない。

0569デフォルトの名無しさん

2009/08/11(火) 13:15:56

>>565の後ろの話で何がいいたいかというと、ちょっとした面倒なことでも
導入や運用のマイナスになるよね、っていいたい。

仕事だから覚えろ、とか使え、ではなかなかすまない話。人は、面倒なら使ってくれないよな。

そういう意味あいで、Dropboxってバージョン管理の利点を学ばせるのにはよかった。
全然ソースコード管理には向かないけど、「履歴が残るのは便利だ」ってのをあまり面倒なく実感できるからね。

うちのバージョン管理使ってない部署で、Dropboxが一気に広まってから、
急に、バージョン管理ソフト使おうと言い出したことがあった。
(俺が同時にVCS導入すると便利だよ、といつも啓蒙活動していたせいもあるが)

連投スマソ

0570デフォルトの名無しさん

2009/08/11(火) 13:43:27

基本的に>>558のプロセスは糞だと思うに一票。
つか、研究かなんかか？

0571デフォルトの名無しさん

2009/08/11(火) 13:52:47

それは言えてるな。
svnよくわかってない人間に>>558みたいな操作はやらせたくないし。

開発の人はsvnの凝った操作を憶えるのが仕事じゃないから、「こうやればできる」
って言っても「そんなわけのわからん操作が必要なツール使うのがおかしくね？」
ってことになる。

0572デフォルトの名無しさん

2009/08/11(火) 14:05:23

うちはそう言う事をやらせたいんならドキュメント書けって言われる

書いても見てくれないんだけどね

0573デフォルトの名無しさん

2009/08/11(火) 16:04:25

シッタカでブランチ切ってマージできないんですけど
って毎度泣きつかれるのも面倒だぞw
頼むから trunk で作業してくれとうまく丸め込むのに苦労した

0574デフォルトの名無しさん

2009/08/11(火) 17:06:32

うちなんてバージョン管理を俺しか使ってないという…無意味にもほどがある。
バックアップ代わりになるから一人でも使ってるんだけどね。
二人以上で同一のファイルに触るなら、バージョン管理したいんだけど、小規模すぎて使う必要ないんかな…。

0575デフォルトの名無しさん

2009/08/11(火) 17:08:21

一人でも慣れちゃうと無いと困るけど
ひとそれぞれかな

0576デフォルトの名無しさん

2009/08/11(火) 17:42:42

>>574
そういう人にはbazaarですよ。
うちでは個人ではローカルで更新続けて、コンパイル完了で中央で上げるって運用している。

0577デフォルトの名無しさん

2009/08/11(火) 22:07:20

俺も一人でも使ってるなぁ。
試し事してるときに、直ぐに戻せるってのは嬉しい。

0578デフォルトの名無しさん

2009/08/12(水) 10:47:39

タイムスタンプ信者がうるさくてSVNに移行してくれない人が数人いるかな

0579デフォルトの名無しさん

2009/08/12(水) 11:23:29

>>578
チェックアウトやアップデートで
mtimeをコミット時刻にしてほしいという人はいたな。
昔ながらにfind -mtimeで変更ファイル一覧を取得したかったらしい。

0580foi.americanprogress.org

2009/08/17(月) 17:49:45

自動焼人 ★　＝　自動保守 ◆KAWORUKOFI　＝　自動保守#K9K?_D[L

名言集　その２
『お前が規制系キャップ取れるか審査してやるよ』

http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/　ID:PVAf+dux0　＝　自動焼人 ★

> 36 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:31:30.02 ID:PVAf+dux0
> >>33
> キャップとコテハンの違いは何？

> 46 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:38:05.34 ID:PVAf+dux0
> >>45
> その回答では落ちるなｗ
> 答えは教えないがｗ

> 50 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:41:29.96 ID:PVAf+dux0
> Q.キャップとコテハンの違いは何？
> A.２ちゃんねるのボランティアの登録制度

> それがお前の答えかｗ

> 52 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:43:10.06 ID:PVAf+dux0
> まぁ、どうせ正解が出るわけもないし、次の問題。
> 君が思う面白いスレはどんなの？
----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください

0581デフォルトの名無しさん

2009/08/25(火) 23:04:52

Mercurialのスレ立てたので宣伝
http://pc12.2ch.net/test/read.cgi/tech/1251208950/

0582デフォルトの名無しさん

2009/08/26(水) 05:38:47

ちょいとお聞きしたいのですが、
とあるプロジェクトAが匿名でとってこれるsvnで用意されてありまして、しかしながら、私はコミット権はもっておりません。

その状態で、そのプロジェクトのパッチを作ったり、弄ったりしつつ、自分の弄った範囲をバージョン管理したいのですが、
よい方法はありませんでしょうか？

通常、分散であれば、cloneとかしたものは、ローカルならコミットできると思うのですが、
svnで匿名で持ってきたものはコミットできませんよね？

ただ単に、svnで匿名アクセスしローカルにもってきて.svnディレクトリを削除し、
ローカルのgitかhg(bzr)に突っ込む、
つまり、単純にソースのみ持ってきて、過去のバージョン管理を破棄し、新たに分散管理するという方法だと、
利便性がない、と感じています。

何かよい方法、ないものでしょうか？

0583デフォルトの名無しさん

2009/08/26(水) 05:46:26

git-svn

0584デフォルトの名無しさん

2009/08/26(水) 08:22:20

bzr-svn

0585デフォルトの名無しさん

2009/08/26(水) 09:27:30

>>582
svk

0586デフォルトの名無しさん

2009/08/26(水) 09:28:10

>>585
いまさらsvkは無いだろ・・・

0587デフォルトの名無しさん

2009/08/26(水) 12:37:53

hg convert

0588デフォルトの名無しさん

2009/08/26(水) 14:35:09

>>587
それじゃ要件を満たしていない。
bzr-svnの場合
1. svn (匿名) からチェックアウトした bzrのブランチA を作成
2. A に変更点をコミット
3. A から新たなbzrのブランチBを作成
4. Bにさらに修正
5. Bから元のsvn(コミット権あり)にpush
6. A が svn(匿名) から pull しても、 (2) で作成されたリビジョンの同一性が保持されて (4) の
リビジョンのみupdateされる。

1-2,6 はsvnにコミット権を持たない外部のコントリビュータの作業
3-5 はsvnにコミット権を持つ人の作業

0589582

2009/08/26(水) 14:48:50

とりあえず、git-svnでやってみました。

リビジョン2300くらいのをhttpごしで取得してみたいのですが、
2000取得したところで、エラーでて止まっちゃう。

git gcが失敗しているみたいなんだけど、どうしたもんでしょうか。これ。

r2000 = ea22187600531bedc9f955737c171a106eaae475 (git-svn)
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Counting objects: 15372, done.
Compressing objects: 100% (15178/15178), done.
Writing objects: 100% (15372/15372), done.
Total 15372 (delta 10985), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
/usr/sbin/git-core//git-repack: line 137: /usr/sbin/git-core/git-update-server-info: Permission denied
error: failed to run repack
gc --auto: command returned error: 255

手動でgit gcしても同じエラーがでてしまいます。

環境は、cygwin git version 1.6.1.2、cygwin UTF-8
リポジトリはマッスルリベンジャーです

>>588
ありがとう。機会があったら、bzr-svnも試してみる

0590582

2009/08/26(水) 14:49:31

コピペミスった・・・

> リポジトリはマッスルリベンジャーです
リポジトリは、http://rubygems.rubyforge.org/svn/ です。

0591デフォルトの名無しさん

2009/08/26(水) 15:46:52

どういうミスだよ

0592デフォルトの名無しさん

2009/08/26(水) 15:52:25

ﾜﾛﾀ

0593デフォルトの名無しさん

2009/08/26(水) 16:20:41

>>588
hg converでsvnからとりこんでhg mergeでいける。
あるいはMQをつかう。

0594588

2009/08/26(水) 16:32:33

>>593
すまん、svnへのpushが要件に含まれて居ないことに今気づいた。

0595デフォルトの名無しさん

2009/08/26(水) 19:28:55

>>589
Cygwinなのが問題なのかも知れない、俺もLinuxでやってみよーと思ったけど、
r2300もフェッチしたらすごい時間かかりそうだし、rubyforgeにもちょっと悪いので、
githubで探してみたら、ミラーがありました。unofficialだけど。
http://github.com/vvs/rubygems/commits/trunk

それでこの後なんだけど、ここのミラーが更新されるのを待つのならば
このまま普通にgitで追いかければいいんだけど、git-svnで追いかけるのであれば、
git-svnのmanページのBASIC EXAMPLESに、やり方が載っています。
しかし、私の経験上、そのままだと何故かうまくいかないので、ちょっとやり方を紹介します。

$ git clone git://github.com/vvs/rubygems.git
$ cd rubygems
$ git svn init --stdlayout http://rubygems.rubyforge.org/svn
$ cat .git/refs/heads/master > .git/refs/remotes/trunk
$ git svn rebase

これでgit svn rebaseがエラーにならなければ、この後普通にgit-svnが使えると思います。

あと、マッスルリベンジャーってなに？ｗ

0596デフォルトの名無しさん

2009/08/26(水) 20:33:05

bzrのミラーもあるよ
https://code.launchpad.net/~vcs-imports/rubygems/trunk

0597デフォルトの名無しさん

2009/08/26(水) 23:58:07

じわじわくるな、マッスルリベンジャー

しかしこれももはや年がばれる系に入ってきてるのか

0598デフォルトの名無しさん

2009/08/27(木) 00:23:23

何度見ても笑ってしまう

0599デフォルトの名無しさん

2009/08/27(木) 00:25:55

最高だｗ
俺もマッスルリベンジャーの名に負けないソフトウェアを作りたいと思う。

0600582

2009/08/27(木) 07:29:22

>>595
おお！githubにミラーがあったんですね！
試しにforkして、cloneで引っ張ってきたらあっという間にローカルに持ってこられました。
自分とこでコミットしたり変更して、パッチ作って送る分にはgithubでいいのかな・・・。

git-svnのやり方も紹介していただいてありがとうございます。
後で試してみたいと思います。

>>596
launchpadにもミラーが！サンクス!!
こういうときには、ミラーがあると助かりますね。

> あと、マッスルリベンジャーってなに？ｗ

・・・たぶん、キン肉マンの動画いろいろ見てたからクリップボードにはいってたんだと思う・・・
YouTube - キン肉マン・キン肉星王位争奪編°マッスル・リベンジャー
http://www.youtube.com/watch?v=sBv49dL2fGs

0601デフォルトの名無しさん

2009/08/31(月) 17:34:08

git-svn って >>588 みたいに一つの svn リポジトリと不特定多数の git リポジトリの間で
分散バージョン管理できるの？
それとも、svnを中央リポジトリとして使わないといけなくて、git <-> git 間でやり取りしたリビジョンと
svn上のリビジョンの整合性は取れなくなる？

0602デフォルトの名無しさん

2009/08/31(月) 19:14:09

>>601
git-svnは、svnリポジトリを中央にしないとダメだと思う俺の知る限り。けっこうこれキツい。
git同士ならぐるっと回って上流から戻ってきたコミット（内容は一緒だけどハッシュ値は違う）
があっても、rebaseした時にいい感じに上流のを採用してくれたりするんだけど、
svn <=> git<->git<->git という感じだと、すべてのgitはsvnにrebaseしていかないといけない。

Subversion1.5のmerge-trackingを利用して、mergeコミットぽく解釈したりできれば、、、とか
妄想するんだけど、できないもんかね。

svkが終了したので、svn <=> svn間のマージもどうしたらいいもんか、悩み中。

0603デフォルトの名無しさん

2009/09/01(火) 00:01:58

>600
>launchpadにもミラーが！サンクス!!

何故かlaunchpadを「レオパルドン」と空目してしまった。
明日眼科逝って来る。

0604デフォルトの名無しさん

2009/09/01(火) 10:51:14

なんだこのスレ肉マニアのおっさんばっかりかｗ

0605デフォルトの名無しさん

2009/09/01(火) 15:51:45

>>604
レオパルドンは肉じゃなくて、たぶん…

まぁ、止めておこう…

0606デフォルトの名無しさん

2009/09/01(火) 16:03:56

　　　　ﾍ⌒ヽﾌ
　　　（　・ω・）　㌧
　　　/ ~つと）

0607デフォルトの名無しさん

2009/09/02(水) 12:21:54

　||　　／￣￣￣￣￣￣￣￣￣￣￣￣
（＋）＜　次峰レオパルドン逝きます！
　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿

　　　||　　　　／￣￣￣￣￣￣￣
　　（＋）　　＜　グオゴゴゴ！
　/（ ┴ ）ヽ　＼＿＿＿＿＿＿＿
　　ヽ＿/
　　／　＼三　)))

　　　　　　　　　　　　　||　　　　／￣￣￣￣￣￣￣
　ﾉｰｽﾞﾌｪﾝｼﾝｸﾞ!! ＼（＋）／　＜　ぎゃあぁぁ！
===============⇒※；）　　　＼＿＿＿＿＿＿＿
　　　　　　　　　　　ヽ＿/∴．:
　　　　　　　　　　　／　＼∵;.;

　　　　　　　　　　　ミ
　　　　　　　　＼　　／　　ｽﾞﾝ!!
　　　　　　　　　二二＋＝
　　　　　　　　／　　＼

0608デフォルトの名無しさん

2009/09/02(水) 12:23:56

うざい

0609デフォルトの名無しさん

2009/09/03(木) 18:37:56

>>602
svn merge で cherrypick merge とかどうなん？
bzr-svn でも bzr merge で cherrypick merge できるし。

0610デフォルトの名無しさん

2009/09/05(土) 03:54:52

IBMのRationalClearCase（クリアケース）って言う
バージョン管理システムって相当酷いものだと聞いた。

http://www-06.ibm.com/software/jp/rational/products/scm/cc/

担当部署の人間の話だと
値段は凄まじく高い上に、制限が多いとかでほとんど使い物にならない詐欺に近い製品って話だ。
IBMのぼったくり商法に騙されたのかも知れないけど、
うちの会社もこのRationalClearCaseをCVSから一部切り替えて運用し始めてしまって引っ込みが付かなくなってしまった。
「CVSは無料だし機能的にもよっぽど使いやすい、有料ならVSSを使った方がマシ・・・」とは担当者談。
そもそもこのIBMRationalClearCase（クリアケース）はメジャーなソフトではないので、設計や導入にもかなり苦労するようだ。
CVSからの移行の工数を聞いただけでぞっとした。
こんなの売りつけられたなら、その会社はIBMのカモにされてると思ってほぼ間違いないんじゃないかと思う。

0611デフォルトの名無しさん

2009/09/05(土) 04:20:04

>>610
元々のRationalがIBMに買収される前はそれなりだったらしいが、
買収されて以降殆ど更新されてないのだろうからいい訳がない。
つーか、企業で導入って、どんな情報弱者だよw

0612デフォルトの名無しさん

2009/09/05(土) 04:23:30

無能担当者とその暴走を抑えられない体制はどうでもいいとして。
IBMにしてみれば顧客が居るから捨てられないんだろ。
Linuxを推し進めているのにAIXの開発から手を引かないIBMらしいエピソードだね。

0613デフォルトの名無しさん

2009/09/05(土) 04:39:15

つーか、IBMにとっちゃRationalTeamConcertとかRationalAppScanが欲しくて買収したらおまけについて来たようなもんだろ。

0614デフォルトの名無しさん

2009/09/05(土) 08:23:18

評価もせずにホイホイ導入するのか
普通の会社なら潰れる

0615デフォルトの名無しさん

2009/09/05(土) 09:14:25

評価版もあるのにねぇ。

0616デフォルトの名無しさん

2009/09/05(土) 10:33:37

うちは弱小ソフトハウスなので、その辺の事情ってよくわからんのですが、
評価はともかく(いや必要だけど)、評判とか情報が少ない製品をなぜ選ぶもんなんでしょうか？
いくら商用で、サポートとかあっても、そんなんなら、まだ情報が大目のOSSとか選びたくなるもんですけど。

0617デフォルトの名無しさん

2009/09/05(土) 12:09:43

>>616
・自分より詳しい奴がいるのが嫌。
・コンサル/営業に吹き込まれた。
・キックバックをもらった。

0618デフォルトの名無しさん

2009/09/05(土) 13:05:48

「あのIBMが出してる製品なんだから、間違いありませんよ」
なんて言われて真に受けちゃったとか。

0619610

2009/09/05(土) 14:30:01

>>611-618
IBMRationalClearCase（クリアケース）なんて採用する時点で
上層部の人間が情報弱者（プロダクトの詳細も知らない、実際の現場の内情も知らない）というのは認めるが、
パートナーのIBMにすすめられてしまったら断れないという政治的な理由もあって、
一度決まったらトップダウンで話が進んでしまうんだよな。
いわゆる、上層部双方が自己満足して、後々になって現場だけが苦労するパターン。
IBMRationalClearCase（クリヤケース）がIBMに買収されてからというもの
更新もなく将来性が全くなくなったプロダクトになり下がっているのに
敢えてリスクを冒す必要があるのか？とか、
今までCVSやVSSで問題なく運用できているのに、
この不景気に無駄な資金をかけてまで果たしてやる必要があるのか？ということが問題になっているみたいだ。
CVSやVSSの開発やサポートが終了するから移行しなければならないというような必然的理由があるならまだしも
すでにある程度シェアを持っているCVSやVSSみたいなメジャーソフトが早々になくなるわけもない。
今までならCVSやVSSはどこの部署でも使っているから新たにバージョン管理を構築する際もハードルは低かったんだけど
IBMRationalClearCase（クリアケース）は超マイナープロダクトだから、
メンテナンスをする人員も新規に育成しなければならないし、
他部署向けの勉強会やらでコストだけが発生しているみたいだ。
今は、一部の部署でIBMRationalClearCase（クリアケース）になっているんだが、
他部署もそこに相乗りしろという話になってきているらしく大迷惑を被っている。
うちの部署に限って言えば、IBM製品はホームページビルダーやノーツを導入させられた経緯があるけど、
もしクリアケース導入ということになるとインパクトはでかいかも知れない。
というか、みなさんが言うように、クリヤケースはプロダクトの質が悪すぎるので積極的に使いたいとは思えない。

0620デフォルトの名無しさん

2009/09/05(土) 15:13:12

わかった！

git-clearcase とか、 bzr-clearcase とかを作って、
自分たちは、好きなSCMをつかって、うpするとき clearcase にすれば良いんだ。

あっ、そうか！！

っていうか、cvs-clearcase とか作れば、今まで手順そのままで、
うpするときだけ、clearcase に…

0621デフォルトの名無しさん

2009/09/05(土) 15:16:59

>>619
そういった分野では、今でもCVSやVSSが主流なんでしょうか。
gitやbzrとは言わないまでも、せめてSubversionぐらいにはならないのでしょうか。

0622デフォルトの名無しさん

2009/09/05(土) 15:20:09

これ買ってもらえ
http://www.clearvision-cm.com/clearvision-products/clearcase-and-git-bridge-cc2git/ash_flypage.tpl.html

0623デフォルトの名無しさん

2009/09/05(土) 15:38:39

CVSのところは某有名SIerを含めて未だ未だ多いよ。
VSSは流石に減ってきているようだけど。
皮肉なことに、逸早くCVSを導入したところほど移行できなくなっている傾向がある。

0624デフォルトの名無しさん

2009/09/05(土) 17:14:04

IBMのSynergyっていう構成管理ツール、使ったことある人いませんか?

0625デフォルトの名無しさん

2009/09/05(土) 17:37:08

>>619
現場の意見虫で、パートナーの提案をはいはい聞いちゃうのってすごいなー。

例えば、パートナーが「アナルセックスがしたい」と言い出したら、はいはいとケツ突き出すんだよなあ。
あげくに、パートナーが「スカルファックしたい」とか言い出した日には・・・
考えられねえ・・・

0626デフォルトの名無しさん

2009/09/05(土) 18:47:08

>>625
ケツ突き出すとかは論外だけど、>>619みたいにパートナー製品を持ち上げることによって
受注が見込まれて事業が継続できるのなら、会社組織としてはしょうがないかもね。
利益が出せなければ事業縮小してバージョン管理どころじゃなくなるとか。
そういうのを肯定するわけじゃないけど、そういう弱い立場の事業経営をやらなくてはいけない場合も
現実としてあるのだろう。

0627デフォルトの名無しさん

2009/09/05(土) 18:53:35

>>625
何も考えずに批判する立場って楽だよね。

0628デフォルトの名無しさん

2009/09/05(土) 18:54:59

まるで野党だなｗ

0629デフォルトの名無しさん

2009/09/05(土) 19:06:00

バージン管理システムってなんかヤラシイな・・・

0630デフォルトの名無しさん

2009/09/05(土) 19:06:41

むしろ肯定するためにあえてあのように書いた可能性もあるが
626は大人だな。

0631デフォルトの名無しさん

2009/09/05(土) 19:24:06

共通部だけCVSやSubversionにしといて個人個人は分散系の使うって方法もある

0632625

2009/09/06(日) 07:11:11

冗談でいったんだけど(´･ω･`) ギャグ通じてない・・・

0633デフォルトの名無しさん

2009/09/06(日) 10:13:07

>>631
そういうふうにやってみたがコミットが二度手間になって面倒くさくて
メリットがかなり薄くなってしまうように感じた。
gitかhgに余所のリポジトリ/ディレクトリとコマンド一発で同期してくれる
ような機能ってつかないものかな

0634デフォルトの名無しさん

2009/09/06(日) 11:36:41

>633
二度手間ってローカル分とリモート分ってことだよな？
これを分けない上で分散型が得るメリットってなんだろう？

0635デフォルトの名無しさん

2009/09/06(日) 11:47:14

>>634
commitとpush+pulllじゃなくて
1プロジェクトがsvnとgit/ghに分かれるのがいやといっているのではないか

0636デフォルトの名無しさん

2009/09/06(日) 11:52:54

>>633
git-svnとかhgsvnではなく？

0637633

2009/09/06(日) 14:20:08

欲しいのはgit-svnのようなものなんだけど、中央リポジトリがsvnやcvsのような
メジャーなものじゃないからgit-svnみたいな便利なものはないし誰かが作ってく
れることも期待できないんだ。
でまぁそういう理由で余所で更新され続けるディレクトリをあまり手間をかけずに
上手く同期してくれるような機能が組み込みであればなぁと。
まぁそんなんじゃ何かの拍子に壊れてどうにもならなくなりそうなのでほんとに
欲しいのは「git-svnの作り方」みたいなドキュメントかもしれない･･･。
ちょっと言葉足らずで誤解させたようですまんかった。

0638デフォルトの名無しさん

2009/09/07(月) 00:07:07

>>619
なかなか縁がないアプリだし、価格がいくらなのかは全く知らないが、Clearcaseっつーのが糞ソフトだということはよーく分かった。
そもそもIBMがそんなもんを出してることすら知らんかったわ。
まあ、フツーに考えてCVSでいいだろ。
しかしうわかたの連中ってどこまでお馬鹿なんだ？
ネット検索して製品情報ぐらい集めるだろフツー。

0639デフォルトの名無しさん

2009/09/07(月) 08:47:08

>>632
それはギャグじゃなくて皮肉だ

0640デフォルトの名無しさん

2009/09/07(月) 09:43:01

rational と言えば、有用なのって purify くらいだと思ったけど…
rational の BTS 使ったことあるけど、あれもひどかった。

0641デフォルトの名無しさん

2009/09/07(月) 19:17:23

>>640
Roseは？
これがメインだと思ってたが。

0642デフォルトの名無しさん

2009/09/07(月) 19:56:27

>>641

さらば「Rational Rose」、買収製品に順次移行へ - ニュース：ITpro
ttp://itpro.nikkeibp.co.jp/article/NEWS/20081007/316339/

0643デフォルトの名無しさん

2009/09/07(月) 21:10:42

RationalRoseなくなったら
もはやRationalじゃないじゃんって感じだね。
つか、テレロジックのRhapsodyってのはどうなのよ？
RationalRose無き後は
RasionalClearCaseを看板にすればいいかもね。

0644デフォルトの名無しさん

2009/09/07(月) 22:57:55

VisalTestバリバリの俺が通りますよ

0645デフォルトの名無しさん

2009/09/08(火) 01:05:29

今って何が流行なの？

みんなで書いてるソースはサーバーにsvn+sshと
なんかTracとか言うwiki連動させて
wikiでバグとか要求管理してんだけど

個人でやる場合はトータスSVNで普通に自分のマシンにリポジトリ作ってるだけだな

0646デフォルトの名無しさん

2009/09/08(火) 01:06:53

TracのWiki使ってるとかマゾヒストか

0647デフォルトの名無しさん

2009/09/08(火) 01:11:52

>>646
15人くらいのプロジェクトだけどガチで書いてる
マジめんどいから俺は嫌なんだ・・・

まあバグをあげるとき、要求をあげるとき、ToDoをあげるときって
wikiの雛形は決まってるんだが
いちお、svnと連動もしてるしな、その機能使ったこと無いけど・・・

バグ管理は何が流行なんだ？もちろんフリーでだ

0648デフォルトの名無しさん

2009/09/08(火) 01:15:04

普通はチケットの方を使わないか

0649デフォルトの名無しさん

2009/09/08(火) 01:19:42

>>648
あー、チケットももち使ってるぞ
マイルストンに向けて、openなの何個みたいな感じで
ただ、詳細な情報を書くときにwikiになるんだわ、これがだるい

0650デフォルトの名無しさん

2009/09/08(火) 01:32:10

Tracのwikiのクソさには定評がある
RedmineだろJK

0651デフォルトの名無しさん

2009/09/08(火) 01:37:37

>>650
さんくす、Redmineな
軽く環境作ってみて、よさげだったら提案してみるわ

0652デフォルトの名無しさん

2009/09/08(火) 02:22:10

詳細な情報もチケットに書くのが普通だと思う
添付ファイルとかつけられるでしょ
Wikiの部分はサーバ設定とかそういう共有情報をまとめる所じゃね

0653デフォルトの名無しさん

2009/09/08(火) 06:51:58

うちはRedmineでやってるが、何故チケットを使わんのだｗ Tracのチケット管理はそんなにクソなのか？ｗ

0654デフォルトの名無しさん

2009/09/08(火) 07:10:20

>>646, >>650
そうなの？Trac Wikiの方が書きやすいと思うけど？どの辺が気になるの？
好みの問題もあると思うけど、textile記法とmoinmoin記法ではmoinmoinの方が
Wikiコードをメールに貼り付けた時に読み易いし、いいと思うんだけど。
(慣れが大きいと思うけど)

Wikiめんどくせとかいうけど、
用語定義とか、まとめに使う分には参照・更新両方のバランスを考えるとかなり効率的な部類なのでは？

0655デフォルトの名無しさん

2009/09/08(火) 08:34:24

Tracは基本的に良いけど、Wikiの編集はローカルでテキストエディタでしたい。
Wikiの内容を分散バージョン管理したい。

今、Launchpad4の要望調査で(Bazaarでバージョン管理された)Wikiというのが
要望高いから、moinmoinのバックエンドをBazaarに置き換えたのが開発されないか
wktkしてるところ。

0656デフォルトの名無しさん

2009/09/08(火) 11:05:26

>>654
うちはRedmine使ってるけど、Wikiはページ名を決めるのが面倒くさい。
イテレーションごとの仕様書とかはリポジトリに突っ込むから、
そっちの補足情報とかはWikiではなくチケットに書いてる。

0657デフォルトの名無しさん

2009/09/08(火) 12:17:21

gitの質問よいでしょうか？
指定のリビジョンの指定のファイルを取り出したいのですが、どうしたらよいのでしょうか？
git checkoutはなんか取り消す？というような記述で違うようですし・・・

0658デフォルトの名無しさん

2009/09/08(火) 12:19:46

git show?

0659デフォルトの名無しさん

2009/09/08(火) 21:36:47

Trac の Wiki が弱いのはわかっていますが、
うちの会社では未だに {{{ほげほげ}}} でチケットを書いてくるような池沼を相手にしなきゃいけないので、
Trac とか何とか、それ以前の状況でつ。 (鬱

0660デフォルトの名無しさん

2009/09/08(火) 22:43:28

ちゃんとpreformatted textの指定してくれるだけましじゃんw

0661デフォルトの名無しさん

2009/09/08(火) 23:24:43

>>659
あー、全文preで書いてんのかｗ　見るねそれｗ
textileとかmarkdownとかはてな記法とか、いっぱいありすぎて頭こんがらかってくるけど、
どれもやりたいことは数パターンで、使ってるうちに憶え、使わないうちに忘れる。
最近trac使ってないから忘れちまったなぁ。

0662デフォルトの名無しさん

2009/09/08(火) 23:29:49

gitはギトギトしててキモイ
いかにもオタソフトって感じがダメダ

消えてなくなれ

0663デフォルトの名無しさん

2009/09/08(火) 23:41:03

たまに居るね～、アンチGit。なんだかなぁ。。。

0664654

2009/09/08(火) 23:50:00

>>656
うちも仕様書等の補足情報はTicketに記述するようにしてる。仕様書作成タスクとして定義する感じで。
確かにWikiページ名はある程度課題を走らせてからでないとしっくりこないですね。

Ticketとの比較という意味で、WikiのいいところはTrac上の記述内にWikiページ名である時に自動的にリンクが生成されるところですね。
なるべくWikiには再利用される可能性が高い用語を定義するようにしてるんだけど、
Ticket内の記述が自然にマークアップされるようになるとWikiってすげーって思える。

>>659
人によっては改行が全くない状態で入れられたり。。
そういう人が多数派にならないように地道にまともな記述を増やしています。

0665デフォルトの名無しさん

2009/09/09(水) 00:33:38

そろそろうざいんですが

0666デフォルトの名無しさん

2009/09/09(水) 01:02:28

そういえばDAVは動きは無いのかな？
記憶が確かならVはバージョニングだったハズ

0667デフォルトの名無しさん

2009/09/09(水) 02:52:26

そもそもBTSスレってなかったっけ、と思ったらあった。
http://pc12.2ch.net/test/read.cgi/tech/1244347242/

0668デフォルトの名無しさん

2009/09/09(水) 07:31:51

BTSスレ池

0669デフォルトの名無しさん

2009/09/10(木) 13:58:01

ファイルが巨大だったり沢山ありすぎるような場合は
git以外の選択肢はないのでしょうか

0670デフォルトの名無しさん

2009/09/10(木) 14:10:24

別に何でもいいと思う
巨大ってのが1ファイルでギガとかじゃなければ

0671デフォルトの名無しさん

2009/09/10(木) 14:14:16

squidのキャッシュフォルダーをまるごと管理しようと思っているのでギガのファイルもあるかもしれないです

0672デフォルトの名無しさん

2009/09/10(木) 17:10:56

>>671
なんか面白そうだな。archive.orgみたいなものを作るの?

0673デフォルトの名無しさん

2009/09/10(木) 17:54:54

>>671-672
ついでキャッシュの情報をp2pで共有できたら、
ペッパーランチみたいな事件で大活躍だな

P2Pと相性よさそうなのはdarcsか？しかし日本語がなあ

0674デフォルトの名無しさん

2009/09/10(木) 18:27:01

分散バージョン管理をバックエンドにしたp2pのwebアーカイブ(キャッシュ、魚拓)みたいなのかｗ面白いなそれ

0675デフォルトの名無しさん

2009/09/10(木) 18:40:10

>>669
gitでも何でも厳しいだろ。ｊｋ
ファイルコピーだけでもかなりの時間が。

0676デフォルトの名無しさん

2009/09/10(木) 19:37:09

ポスグレのblobなんかで自作したほうが早い希ガス

0677デフォルトの名無しさん

2009/09/11(金) 09:34:41

git か何かはバイナリも差分で管理しなかったっけ

0678デフォルトの名無しさん

2009/09/11(金) 11:10:27

gitは差分じゃなくて圧縮してまるごとだから、逆に向かないような

0679デフォルトの名無しさん

2009/09/11(金) 11:27:30

バイナリの扱いは、
svnはxdelta
cvsはそのまま
gitはまるごと(バイナリ以外も)
ほかは知らない

0680デフォルトの名無しさん

2009/09/11(金) 11:27:36

そうか。何かバイナリを差分で扱うのがあったような。BitKeeper?

0681デフォルトの名無しさん

2009/09/11(金) 11:44:44

>>680
>>679にあるsvnのxdeltaってのはバイナリ差分(のアルゴリズム)だよ。

0682デフォルトの名無しさん

2009/09/11(金) 12:07:17

>>679
> gitはまるごと(バイナリ以外も)

　ｲ｀ﾍ
　/: :| ヽ
/ : :/　　ヽ　＿＿＿　　　_,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡　/
　　　　　 ( : : : : : : : : : : : : : : ｀ゝ　 /
　　マ　　r::/: /: : | : : : : : : : : ::＼ /
　　　　//: /: : : |: : | |: : |: _: : : :ヽ
　　ジ　 {/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
　　　　　〉 ,‐-‐､｀|7　|| |_::|,_|: : :|:::|: |
　　で　／ r:oヽ`　　　/.:oヽヽ: :|: | :|
　　　　{　{o:::::::}　　　　{:::::0　}/: :|N
　　っ　 |　ヾ:::ソ　　　　ヾ:::ｿ /|: : |
　！？ヽ::::ー-..　／ヽ　..ー-::: ヽ::|　r--ッ
-tヽ／´|｀::::::::::;／　　 `､ ::::::::::: /: i　}　＞
::∧: : :|: |J　　＼　　／　　／::i: | /＿ゝ
. ＼ヾ: |::|｀ - ,, ___｀-´_ ,, - ´|: : :|:::|
　　ヽ: |::|＼　　　￣/ /|　　|: : :|: |

0683デフォルトの名無しさん

2009/09/11(金) 12:08:39

クリアケースは糞

0684デフォルトの名無しさん

2009/09/11(金) 12:42:21

>>682
それでもリポジトリのほうが小さかったりするけどね。
例えばlinux-2.6はソースが404M、全履歴含むリポジトリが352M。

0685デフォルトの名無しさん

2009/09/11(金) 13:35:59

まるごとつーても、packはあるからな。

0686デフォルトの名無しさん

2009/09/11(金) 15:43:59

>>685
packって
差分を取り出すかわりに
複数の履歴を一まとめに圧縮することで重複をなくすってことか?

0687デフォルトの名無しさん

2009/09/11(金) 16:53:30

そろそろCVSから移行しようかと思うんですが、
subversionとmercurialのどちらがおすすめですか？

0688デフォルトの名無しさん

2009/09/11(金) 16:54:59

そう言う聞き方をするバカにはSVN使ってれば良いと思います

0689デフォルトの名無しさん

2009/09/11(金) 17:35:13

そう言う聞き方をするバカにはCLEARCASE使ってれば良いと思います

0690デフォルトの名無しさん

2009/09/11(金) 17:48:35

git がいいと思うけどなー

0691デフォルトの名無しさん

2009/09/11(金) 18:06:47

集中型に比べた分散型のメリットがわからないのでsvnのまま現在に至る。

0692デフォルトの名無しさん

2009/09/11(金) 18:39:00

>>687
CVS→Subversionの方がCVS→Mercurialよりも覚えることが少ないので
まずはSubversionを使うのがいいと思います。

0693デフォルトの名無しさん

2009/09/11(金) 18:39:32

フリーでバイナリー差分ができるのがsvnのみってことでいいの？

0694デフォルトの名無しさん

2009/09/11(金) 18:45:34

>>693
バイナリ差分って具体的に何？
バイナリファイルのdiffをパッチとして送るってこと？
それともリポジトリの格納形式を気にしてる？

0695デフォルトの名無しさん

2009/09/11(金) 18:50:43

svn updateしてdllとか更新されたときにmergeって表示される時があるけど
恐いから削除して更新し直してる

0696デフォルトの名無しさん

2009/09/11(金) 22:19:03

>689
cleacaseってそんなにいいの？？

0697デフォルトの名無しさん

2009/09/11(金) 22:28:03

Rubyでできたオブジェクト指向なバージョン管理システムはありませんか？

0698デフォルトの名無しさん

2009/09/11(金) 22:31:26

そういえばRuby製は聞かないな。
オブジェクト指向なVCSってのは何を指してるのかわからんが。

0699デフォルトの名無しさん

2009/09/11(金) 22:56:38

>>691　俺もそう思う。
分散型といっても最終的にはマージしなくちゃならないんだから、差異が多くなる前にマージしないと競合が激しくなるんじゃないのかな。
こまめにマージするなら集中型と変わらないんじゃないかな？

0700デフォルトの名無しさん

2009/09/11(金) 23:13:14

>>699
分散型は、よくあるコミット権云々のしがらみから解放される。
パッチ送ったのになんで取り込まないんだよ云々からも解放される。

0701デフォルトの名無しさん

2009/09/11(金) 23:21:00

誰でもコミット（push?)できるの？怖くない？

0702デフォルトの名無しさん

2009/09/11(金) 23:26:57

>>701
自分ちにコミットしても誰も怒らないよ

0703デフォルトの名無しさん

2009/09/11(金) 23:43:48

それなら集中型でも俺んちリポジトリを作れば一緒のような気がする。
元が更新されても差分を俺んちリポジトリにマージすればいいんだし。

0704デフォルトの名無しさん

2009/09/11(金) 23:49:22

3way mergeうんぬん

0705デフォルトの名無しさん

2009/09/11(金) 23:58:59

>>704なるほど。
分散型はmergeが偉いという認識でいいの？

0706デフォルトの名無しさん

2009/09/11(金) 23:59:28

>>703
その通りなんだが、集中型はもともとそういう用途向けに作られてないし、
そうやって俺んちリポジトリにマージしながら使うのって、
『集中』してないよな…
そういう用途には分散型が適してる。

0707デフォルトの名無しさん

2009/09/12(土) 08:38:01

>>679 >>684
本当だ。700kbのexeバイナリつっこんで、毎回コンパイルするのを想定して、バイナリエディタで弄ったのをコミットしたら、
毎回圧縮されたと思わしき、400kbずつリポジトリが増えていった。

githubにexe突っ込むのやめないといけないな、これは。

0708デフォルトの名無しさん

2009/09/12(土) 08:39:25

>>703
使い方がまさに分散型なのだがｗ

0709デフォルトの名無しさん

2009/09/12(土) 08:44:50

実効ファイルの差分ならgoogleが凄いの出してたな。courgetteってやつ。逆アセしてdiff取るらしい。

0710デフォルトの名無しさん

2009/09/12(土) 09:43:04

>>709
Chromeの更新に使ってるやつだね。
確かに逆アセまでやるところがすごいと思ったわｗ

0711デフォルトの名無しさん

2009/09/12(土) 10:08:21

>>709
Google Chromeのソフトアップデート用圧縮技術Courgetteが面白そうなのでちょっと考えてみた ([email protected])
http://blog.browncat.org/2009/07/google_chrome_courgette.html

これか。
逆アセしてテキストで差分とる？だろ、パッチあてるときどうすんのかな。
パッチあてるexeを逆アセして、パッチあてて、またアセンブルするってことか？

0712デフォルトの名無しさん

2009/09/12(土) 10:33:38

完全な逆アセンブルまではしてないんじゃないかなあ。
単なるバイト列じゃなくて、各命令の境界やオペコードとオペランドの境界を見た上で
いろいろやるってことじゃないかという気がする。
オペランドに即値やアドレス指定がある場合にも何かやるんだろうけど。

0713デフォルトの名無しさん

2009/09/12(土) 10:39:07

>>697
MercurialもBazaarも、Python2.4から2.6で動く。2.4が出たのは2004年だ。
Rubyだと1.8.2が出たころだけど、Rubyで1.8.2から1.8.7までサポートするのはPythonよりも
大変だろう。
WindowsのサポートもPythonに比べてRubyは貧弱。
使い捨てWebアプリならともかく、VCSをRubyで作る利点は無いな。

0714デフォルトの名無しさん

2009/09/12(土) 15:30:26

Ruby界隈であんだけgit広まってるわけで、わざわざ作る理由がないな

0715デフォルトの名無しさん

2009/09/14(月) 03:38:00

git logしたときに，コミットメッセージが長いとターミナルに全部表示されないんだけど，
長いメッセージを自動で折り返すようにするにはどうしたらいいの？
ちなみにcygwin上で使ってます．

0716デフォルトの名無しさん

2009/09/14(月) 07:59:23

>>713
>Rubyだと1.8.2が出たころだけど、Rubyで1.8.2から1.8.7までサポートするのはPythonよりも
>大変だろう。

まったく逆。Rubyは1.8.6まではバグフィックスが主だから、1.8.xをサポートするのは簡単。1.8と1.9の両方をサポートするのも難しくない。
Pythonは2.4と2.5と2.6で機能が大幅に強化されている。2.5や2.6の新機能を使うと2.4ではうごかないし、新機能を使わないとコード書くのが面倒。
しかも2.xと3.0の両方で動かすのはほぼ無理。hgとbzrが3.0で動くようになる日はいつだろう。

0717デフォルトの名無しさん

2009/09/14(月) 09:41:20

>>716
Ruby脳に犯されていないか？言語仕様だけでなく標準ライブラリのことも考えてる？
Ruby は x.y.z の z の変更だけで新機能が入る。 Python は z の変更はバグフィックスonly.
Ruby で 1.8.2 ～ 1.8.6 に対応しようと思ったら、Pythonの 2.4 ～ 2.6 と同じく途中から入った
機能は使えない。
後はどれくらいバージョン間の互換性が取られていたり移行がサポートされているかだけど、
Pythonは互換性を破壊するような変更は基本入らない。どうしても古いAPIと互換性の無い
拡張をしたかったら、urllibとurllib2があるようにパッケージを分けて互換性を壊さない。

実際問題、Rubyは使い捨てWebアプリでよく使われていて、Pythonはいろんな場所で継続して
使われてるだろ。

0718デフォルトの名無しさん

2009/09/14(月) 10:35:46

>>717
最近のRubyしか知らない人なら、大きな差と言えば1.8.6前後や1.9の差
くらいしか知らないだろうから、それ以前の差異を軽く見てるかもしれな
いけど、それ以前からRuby使ってるなら>>716みたいなたわごとは言わ
ない。1.8系間での互換性のなさは身を持って知ってるはずだから。

0719デフォルトの名無しさん

2009/09/14(月) 10:37:24

>>717
>Ruby は x.y.z の z の変更だけで新機能が入る。

具体的にどんな機能？1.8.7はそうだけど、それ以前ではめぼしい物は思いつかない。
あとRubyは x.y.z.p だからね。Pythonとバージョン番号の付け方が異なるのに、同じように論じてる717は可哀想なひと。

> Ruby で 1.8.2 ～ 1.8.6 に対応しようと思ったら、Pythonの 2.4 ～ 2.6 と同じ> く途中から入った
> 機能は使えない。

だから具体的にどんな機能が1.8.xで入ったの？

0720デフォルトの名無しさん

2009/09/14(月) 10:39:43

>>719
わかっててきくな。

お前らそろそろアンチRubyスレにいけ。鏡で顔見ろ

0721デフォルトの名無しさん

2009/09/14(月) 10:39:58

>>718
>1.8系間での互換性のなさは身を持って知ってるはずだから。
具体的にどうぞー！

0722デフォルトの名無しさん

2009/09/14(月) 10:43:11

>>720
なにこいつ、具体的な内容なにひとつわかってないのに罵詈雑言まきちらしてたわけ？アンチRubyキモー！

0723デフォルトの名無しさん

2009/09/14(月) 10:47:08

これぐらいで満足していただけないでしょうか？
http://www.ruby-lang.org/ja/man/html/ruby_1_8_2_feature.html
http://www.ruby-lang.org/ja/man/html/ruby_1_8_3_feature.html
http://www.ruby-lang.org/ja/man/html/ruby_1_8_4_feature.html
http://www.ruby-lang.org/ja/man/html/ruby_1_8_5_feature.html

0724デフォルトの名無しさん

2009/09/14(月) 11:20:43

それ読んだのか？基本的にバグフィックスと、軽微な仕様変更だけじゃないか。
互換性がなくて困るほどの仕様変更ってどれさ？1.8.2から1.8.7までをサポートするうえで困る仕様変更って何？
>>718
>1.8系間での互換性のなさは身を持って知ってるはずだから。
1.8.2から毎日使ってるけど、互換性のなさで困ったことはRuby本体ではない（Railsはしょっちゅう）。
おまえが困った非互換性ってどんなのがあったの？まじで教えてほしいんだけど。

0725デフォルトの名無しさん

2009/09/14(月) 11:39:54

ruby は1.9.2 がstableになった後、gemが安定し始めたら、test始めていいんじゃないかと。
そこそこ混乱するだろうけど、収束は早いのではないかと。

Python は外部ライブラリに頼る物は、世代移行や後方互換が難しい上に、
多方面に影響するので、php4、php5の様に、2.5.4 と3.1.1は別枠で投入された方が良いと思う。

0726デフォルトの名無しさん

2009/09/14(月) 12:17:04

pythonとrubyの戦いは言語スレでやってちょ。

0727デフォルトの名無しさん

2009/09/14(月) 14:36:07

スレタイよめよ・・・

0728デフォルトの名無しさん

2009/09/14(月) 14:37:01

>>720-726
誘導
【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1248487404/

0729デフォルトの名無しさん

2009/09/14(月) 14:47:57

haskellでいいじゃん

0730デフォルトの名無しさん

2009/09/14(月) 15:34:52

Python 3.0 は過去のしがらみを捨てた大掃除なんだから、比べるとしたらRuby 1.9じゃなくてRuby 2.0だろ常考・・・

0731デフォルトの名無しさん

2009/09/14(月) 22:02:51

Ruby1.6 の頃から使ってる俺拡張ライブラリがあるけど
ヘッダが #ifdef だらけでえらいことになっとるｗ

StringPtrとかARRAY_LENとかrb_io_tとか

0732デフォルトの名無しさん

2009/09/15(火) 07:42:27

どっちもどっちのくだらない言語のはなしはいいよ
スレタイ2回読んでくれ

0733デフォルトの名無しさん

2009/09/15(火) 13:39:59

日本語のテキストって、utfにしとけばバイナリじゃない扱いになるの？

0734デフォルトの名無しさん

2009/09/15(火) 14:29:48

>>733
バージョン管理システムによっても違うと思います。
自分が使っているSubversion、Mercurialは
UTF-8はテキストとして差分表示できます。

0735デフォルトの名無しさん

2009/09/15(火) 16:25:41

>>733
Subversionは、確実な方法としてversioned propertyというものを
設定できるので、それで mime-type やら encoding やらを設定しておけば良い。
hgとbzrは、今のところファイル内に '\0' バイトがあるかないかでバイナリファイルか
否かを判別してたと思う。
bzrは将来的にsvnと同じようなプロパティをサポートする雰囲気。

0736デフォルトの名無しさん

2009/09/15(火) 20:21:04

>>735
> bzrは将来的にsvnと同じようなプロパティをサポートする雰囲気。
その点、hgは絶望的だ・・・orz

0737デフォルトの名無しさん

2009/09/15(火) 20:32:06

bzrはsvnと志向が似てる分、svnと同じように完成度が上がるのに時間がかかってる気がする。
もうすぐ2.0になってまともなリポジトリフォーマットがデフォルトになるけど、そのあとにもNestedTreeとか
HistoryHorizonとか、コピーとか、なんでこれがまだねーんだよという機能が保留されてる。

0738デフォルトの名無しさん

2009/09/15(火) 20:56:38

>>737
NestedTreeとHistoryHorizonについて解説よろしく

0739デフォルトの名無しさん

2009/09/15(火) 21:12:42

>>738
NestedTreeは、svnのexternal reference.
ツリー内に他のツリーを含める事。

HistoryHorizonは、git の --depthオプション相当。
古い履歴を切ることで、大きいプロジェクトを初めてチェックアウトするときに
短時間で出来るようにする。

今でも stacked branch とか lightweight checkout という機能があるんだけど、
これは古い履歴を見えないようにするんじゃなくて外部から取ってくる機能なので、
リモートからlightweight checkoutとかしたらオフラインで作業が出来なくなる。
gitのdepthはpushを保障していないけど、bzrはきちんと整合性を維持できる形で
実装したい気持ちはある。気持ちがあるだけで今のところ実装始まってない。

0740デフォルトの名無しさん

2009/09/17(木) 03:22:40

InkscapeのDVCS決めでBzr派とGit派が対立中。
http://www.nabble.com/DVCS-Discussion---Vote-to25430189.html

0741sage

2009/09/17(木) 16:06:42

Mercurial + TortoiseHgの日本語パス及び
日本語ファイル名の問題ってまだ解決できていないのでしょうか？
（SJISというかcp932問題ですかね）
パッチが登録されているようですが、
このパッチが救世主になってくれるのかな？
ttp://mercurial.selenic.com/bts/issue1828

0742デフォルトの名無しさん

2009/09/17(木) 16:43:52

こんなんで、domain 取っちゃうのなw
ttp://bzrvsgit.com

0743デフォルトの名無しさん

2009/09/17(木) 18:22:51

>>741
まだ解決できてない。
fixutf8はフォルダでバグるし…早く何とかしてくれ。

0744デフォルトの名無しさん

2009/09/17(木) 18:37:22

bzr-hgがpushにも対応したら、utf8が完全に動くhgクライアントの出来あがりw
いや、マジでそっちの方が早い気が・・・

0745741

2009/09/17(木) 18:39:25

>>743
そうなんですね…。
ここさえなんとかなれば文句ないんですけれど。

0746デフォルトの名無しさん

2009/09/18(金) 04:45:26

NetBeansのIDEの組み込みのMercurial拡張がUTF8対応してるかもｗ

0747デフォルトの名無しさん

2009/09/18(金) 05:36:21

>>744
bzr-hgってバックエンドにhgのコード使ってたような…

0748デフォルトの名無しさん

2009/09/18(金) 09:34:57

>>747
うん、使ってるよ。
リポジトリを読むところはhgを使っても、それで取り出したUTF-8をBazaarがUnicodeとして
扱ってWindowsのUnicode APIを使ってファイルを保存してくれたら問題解決。
ある意味、fixutf8代わりにBazaarを使うの。
残念ながらまだpushできないから実用にならないけどね。

0749デフォルトの名無しさん

2009/09/19(土) 05:22:34

> 残念ながらまだpushできないから実用にならないけどね。

ダメじゃねーかｗ
でも期待したいなー
bzrがフロントエンドでBitbucket.orgとか使えるようになるかもしれないんだよね？

0750デフォルトの名無しさん

2009/09/19(土) 17:55:57

windowsでまともに使えるのは、いまだにsvnだけ？
hgなら日本語ファイルさえ使わなければ、ソースのコメントに日本語書いても大丈夫？

0751デフォルトの名無しさん

2009/09/19(土) 18:04:44

>>750
問題ない。さすがにファイルの中身については。
TortoiseHgでもちゃんとdiff見れます。

0752デフォルトの名無しさん

2009/09/19(土) 20:52:08

>>750
日本語ファイルでもWindowsのみで運用するなら次のバージョンでほぼ解決かも。
ttp://groups.google.com/group/mercurial-ja/browse_frm/thread/2a25b275f631cea3/1eda88c133016111?hl=ja#1eda88c133016111

0753デフォルトの名無しさん

2009/09/19(土) 23:34:16

>>752
おっ。そんなものが公開されてたのか。
win32mbcs.pyを入れ替えたらTortoisehg0.8.2でも日本語が通るようになった。
フォルダの化け文字についてはまだだめか。

0754デフォルトの名無しさん

2009/09/20(日) 01:06:32

>>753
うまくいったのは日本語ファイル名？
もしファイル名がうまくいったらフォルダ名でもいけると思うけどなぁ。

0755デフォルトの名無しさん

2009/09/20(日) 02:32:06

>>754
管理表.xlsって日本語ファイル名。
ちなみに化け文字が入ったファイル・フォルダを直接コミットしようとすると反応しない。

0756デフォルトの名無しさん

2009/09/20(日) 04:03:23

表
0x5C

0757デフォルトの名無しさん

2009/09/20(日) 04:06:18

VSSの誰かが触ってる間に絶対に触れないって仕組みが納得いかない
アップする気はないけどちょっと弄らないと動かないときってあるだろ
バカヤロー

0758デフォルトの名無しさん

2009/09/20(日) 04:19:19

よく考えないアホには一見正しそうな気がする仕組みだからねぇ
複数のファイルから成るプロジェクトだと気休め以下のゴミ仕様

0759デフォルトの名無しさん

2009/09/20(日) 10:23:05

日付フォルダーをいっぱい作ってる人って、なかなかバージョン管理システムを
使わないね。何でだろう？

0760デフォルトの名無しさん

2009/09/20(日) 10:35:20

聞いてみたら？　たぶん学習するのがめんどくさいからだろう。

0761デフォルトの名無しさん

2009/09/20(日) 10:44:46

>>759
日付フォルダーは目に見えるからわかりやすいんだろうな。
そもそもそういう人たちはバージョン管理システムなんてものを知らないだろう。

0762デフォルトの名無しさん

2009/09/20(日) 10:53:52

ブランチ作るのは仰々しい by新入社員

0763デフォルトの名無しさん

2009/09/20(日) 11:01:11

聞いたらこれでうまく行ってるって言うが、必ずどれが最新かフォルダ主に聞かないと使い物にならない。
日付が新しくてもリリース版とは限らないんだなこれが。

0764デフォルトの名無しさん

2009/09/20(日) 11:17:16

>>755
あー、そうそう。ダメ文字はあいかわらずダメなんだよね。
ttp://www.asukaze.net/etc/vcs/hg-fixutf8.html

0765デフォルトの名無しさん

2009/09/20(日) 11:50:14

>>755
直接っていうのは、エクスプローラでそのファイルを右クリックして、
TortoiseHgのメニューからって意味かな？
シェル拡張関連は右クリックメニュー、アイコンオーバーレイ共にダメかもしれん。
だけど TortoiseHg 0.8.2 と >>752 のメールに添付されてるwin32mbcsで
コミットダイアログから「管理表.xls」を追加したらエラー出なくて、コミットも問題なく通った。
win32mbcsを無効にしてやったらもちろん失敗。

0766デフォルトの名無しさん

2009/09/20(日) 11:53:53

>>764
完全にだめってわけじゃない。
ダメ文字を持つファイル・フォルダを右クリック→コミットの動作は出来ない。

0767デフォルトの名無しさん

2009/09/20(日) 12:01:00

bzr-svnってbzr branchのとき、changesetごとに何かデータ構造をメモリ上に作ったりする？
実メモリが少ないのでスラッシング起こしてbzr branchが終わらないwww

0768デフォルトの名無しさん

2009/09/20(日) 12:56:17

>>759
バージョン管理重過ぎね？
ソース程度ならできるけどソース限定な気がする
仕様書とか無理だろ超重い

0769デフォルトの名無しさん

2009/09/20(日) 12:58:14

1MB前後のレポート作成する限りではTortoiseSVNで管理しても全然重くない

0770デフォルトの名無しさん

2009/09/20(日) 13:47:57

>>768
プロジェクト全体をフォルダに毎回コピーするよりも、変更分だけをコミットするほうが断然軽いよ。
極端な話、ファイルを一回修正保存するたびにコミットしたって問題ないくらいだ。

0771デフォルトの名無しさん

2009/09/20(日) 15:05:41

>>757
Visual SourceSafe のこと？

誤解されがちだけど、オプションに
「複数ユーザによる同一ファイルのチェックアウトを許可」ってのがあるよ。
マージもできる

0772デフォルトの名無しさん

2009/09/20(日) 17:29:59

>>768いったい何ギガの仕様書ですか？
遅いのはLANのせいとか。無線LANだと凄く遅いぞ

0773デフォルトの名無しさん

2009/09/20(日) 19:46:56

>>771
マジか！
しかし、チェック入れてくれないだろーなー
デフォルトの糞さを呪うぜ・・・

>>772
３０ＭＢぐらいだよ
たったこんなんだけど数が増えてくるとすっげ遅いの
もう１０個もコピーしてっと半日作業だよ

0774デフォルトの名無しさん

2009/09/20(日) 19:59:20

>>767
バージョンは何？
bzr-svnのメモリ馬鹿食いが完全に直ったのは決行最近のバージョンだよ。

0775デフォルトの名無しさん

2009/09/20(日) 20:07:11

>>773
30Mを10個で半日というのはあまりにも遅すぎる。何か別の問題ではないか

0776デフォルトの名無しさん

2009/09/20(日) 22:28:40

>>773
とりあえず別のPCとか環境で試してみたらどうよ？

0777デフォルトの名無しさん

2009/09/20(日) 22:42:35

履歴の多さが遅さに直結してるような気がするなぁ～

0778デフォルトの名無しさん

2009/09/20(日) 23:09:44

svnのdumpをsvnで管理したらどうなるかなと思って1G位のdumpをsvnに食わせて試したことも有るけど平気だったけどなあ。
何でだろう。

0779デフォルトの名無しさん

2009/09/20(日) 23:44:28

>>773
そもそもコミットする気がないなら、ローカルファイルのリードオンリー属性外せばいいだけじゃないか？
VSSはしばらく使ってないが、最近はそれだけじゃローカルファイルを編集できなくなったのか？

0780デフォルトの名無しさん

2009/09/21(月) 00:03:13

>>779
結構しつこく撥ねられるんだぜ

0781デフォルトの名無しさん

2009/09/21(月) 00:27:48

そういやTortoiseSVN使ってて、SVNレポジトリをNAS(LinkStation)に置いてたら妙に遅かったな
明らかにネットワーク的遅さとは異質だった

0782デフォルトの名無しさん

2009/09/21(月) 11:04:51

>>781 おいらのNASもそうだ。ファイルの転送速度は十分有るけど。新規ファイルの作成、伸張が遅いようだね。
NASにリポジトリ置くとローカルに比べてチェックアウトの時間は1.5倍、コミット時間は６倍になったよ。

0783デフォルトの名無しさん

2009/09/21(月) 11:19:52

>>782
そもそもHDDのスペックが貧弱なんじゃないの？

0784デフォルトの名無しさん

2009/09/21(月) 11:31:14

>>780
編集したいファイルが沢山あるってこと？
なら、ブランチを作成したほうがいいのでは？
vssはブランチ作成は簡単に出来た記憶がある。
でも、マージは面倒だったっけ？

0785デフォルトの名無しさん

2009/09/21(月) 11:39:28

VSSもマージは簡単だった

0786デフォルトの名無しさん

2009/09/21(月) 11:42:26

使ったことないけど、ではVSSが叩かれるのはなぜ？

0787デフォルトの名無しさん

2009/09/21(月) 11:52:07

昔vssで今svnだけどvssが悪いとは思わないな。
ロックによる方法が古臭いと思うけど、モジュール分けを丁寧にすればロック競合なんて問題にならないし。
しいて言えば、バージョンアップのニュースは聞かないし、高いって所かな。
あとはマイクロソフトだからじゃないか？

0788デフォルトの名無しさん

2009/09/21(月) 12:05:43

元々個人向けあるいは小規模チーム用の製品で MS 自身も使ってない上に
本当かどうかはわからないけどデータが壊れやすいみたいな話があったように思う

0789デフォルトの名無しさん

2009/09/21(月) 13:04:05

>ロックによる方法が古臭いと思うけど、モジュール分けを丁寧にすればロック競合なんて問題にならないし。

そりゃ悪いとは思わないだろうなぁ。

0790デフォルトの名無しさん

2009/09/21(月) 20:53:19

ロック型は複数ファイルを扱うツールやバッチファイルなんかと相性が悪い。
基本的にファイルを書き換える前にロックしなければいけないから、利便性の
ためにツールのプラグインとしてそのロック操作が組み込まれたりするが、そ
のプラグインが大抵親ソフトのバージョンアップについて行かないんで、バー
ジョン管理ツールの都合で開発ツールのバージョンがロックインされてしまう
ということが起こる。

0791デフォルトの名無しさん

2009/09/21(月) 22:40:30

>>788
MSがドッグフードしてないってのはわりと有名な話だよ・・・

0792デフォルトの名無しさん

2009/09/22(火) 02:56:11

MSの内部で
VSSを試したら直したはずのバグがいつの間にか元通りとか。
MS Projectで工程管理していたらスケジュールが破綻したとか。

まあ都市伝説みたいなものだと思うが。

0793デフォルトの名無しさん

2009/09/22(火) 03:14:31

これね
ttp://d.hatena.ne.jp/softether/20060202#p2
[質問]（中略）現在ではどういうツールを使ってバージョン管理を行っているか?
自社内で共通のソースコード管理ツールがあるのでそれを使う。
ソースコードの流れで、たとえばバージョン分岐などの管理もこれでうまくできる。

[質問] では、Visual SourceSafe などは使っていないのか?
Visual SourceSafe は使わない。あれはビギナー (初心者) 向けのソフトだ。

0794デフォルトの名無しさん

2009/09/22(火) 06:15:50

Team Foundation Serverがあるしねぇ。

0795デフォルトの名無しさん

2009/09/22(火) 11:57:23

Visual SourceSafe は 2010 もでないようだし
そろそろフェードアウトくさいけどね

0796デフォルトの名無しさん

2009/09/22(火) 12:10:43

IBMのクリアケース使いにくい・・・

0797416

2009/09/22(火) 12:38:19

bzr-2.0rc2-5 にTBZR 0.3 が入ったのはいいんだけど、シェル拡張部分だけなぜか
0.2の物が入ってて、オーバーレイされるアイコンが間違ってるorz

ちなみに、 TBZR 0.3 では、 >>561 の対策が半分入ってる。
THGと同じように、'unversioned' アイコンをキャッシュされてないファイルにオーバーレイ
表示してる。

0798797

2009/09/22(火) 12:39:03

Bazaarスレに書き込むつもりが誤爆した・・・スマソ

0799デフォルトの名無しさん

2009/09/22(火) 15:45:49

>>797
TBZRは中の人、一人で頑張ってるから勘弁してやってくれ。
つか、こんなとこでボヤいてないでバグトラッカーに報告すればいいのに。

0800デフォルトの名無しさん

2009/09/22(火) 16:39:59

>>799
あえて突っ込む必要があるのかわからんが、(>>797の)416 はTortoiseBzrのTop contributorなわけだがｗ

0801デフォルトの名無しさん

2009/09/22(火) 16:51:40

>>740の結果、InkscapeはBazaarを使うことになった模様。
http://www.nabble.com/DVCS-Vote-Tally-td25502877.html

0802デフォルトの名無しさん

2009/09/22(火) 20:29:18

LinuxやUnix専用のツールはgitで十分、クロスプラットフォームアプリの開発なら
Bazaar、っていう方向性になってきたのかな。
Mercurialは使いやすいgitという感じで、キャラが中途半端だな。

0803デフォルトの名無しさん

2009/09/23(水) 14:09:07

>>774
既知の問題だったんだ。情報どうもありがとう。
bzr-1.18 + bzr-svn-0.6.5 でダメだったから、さっきbzr-1.18 + bzr-svn-1.0.0rc1 で
やってみたけど、メモリ食いまくりは変わらずだった。
BTS見てみたら、メモリ消費関連でまだつぶせてないバグあるみたいだから、
もう少し様子みてみることにするよ。

0804デフォルトの名無しさん

2009/09/23(水) 16:00:13

>>796
クリアケースみたいなろくに書籍も情報もないようなアプリ使うなよ・・・
おとなしくCVSかSubVersion使うことをおヌヌめする

0805デフォルトの名無しさん

2009/09/23(水) 16:00:36

>>803
あちゃー。なんだろ。tdbが有効になってない場合とかにまだ穴があるのかな・・・

0806デフォルトの名無しさん

2009/09/23(水) 22:10:53

>>804
いやいや、クリアケースを使っているということは
恐らく使わざるを得ない状況にあるんだろう

0807デフォルトの名無しさん

2009/09/24(木) 06:35:30

クリアケースってCVSなんかと比べるとかなり後発なんじゃないの？
後発でもダメなソフトっていっぱいあるけどな

0808デフォルトの名無しさん

2009/09/24(木) 20:28:10

ダメでも、IBMと提携してるからとかいう理由で使っているんじゃね？

0809デフォルトの名無しさん

2009/09/27(日) 11:27:25

darcsからbzrにのりかえようとしてるんだけど
bzrはこんなことできます？

python2.5用に作ったコードを別ブランチで管理
python3.0用を別ブランチで管理

必要に応じてpython2.5からpython3.0への変更を残したまま
python2.5用に作った新機能をpython3.0にとりこむ
その逆もする

0810416

2009/09/27(日) 13:10:49

>>809
多分、cherrypickのことを言ってるんだよね。
まだ翻訳中だけどドキュメントはこちら
http://methane.sakura.ne.jp/bzr/user-guide/adv_merging.html

0811デフォルトの名無しさん

2009/09/28(月) 10:50:14

bzr重いね
windowsで使ってると何度も最新に更新ボタンおさないといけない

0812デフォルトの名無しさん

2009/09/28(月) 12:46:45

>>811
それはbzrが重いのかエクスプローラが重いのか、或いはbzrの周辺ツールが重いのか解っているのかな?
ついでに言えば、何と較べて重いと思っているのかな?

0813デフォルトの名無しさん

2009/09/28(月) 13:09:16

>>812
torrtizeSvn使ってた時はもっと軽かった

0814デフォルトの名無しさん

2009/09/28(月) 13:42:54

bzrが重いって言ってるのに、何でエクスプローラの話題を持ち出すのか

0815デフォルトの名無しさん

2009/09/28(月) 14:23:49

>>814
>813
どうやらtortoiseSVNとtortoiseBzrを較べているらしいよ。

0816デフォルトの名無しさん

2009/09/28(月) 16:23:09

は？

0817デフォルトの名無しさん

2009/09/28(月) 22:42:19

>>811
TortoiseBZRの開発者です。よかったら、バージョンとか、具体的な症状とかを
Bazaarスレかgoogle groupsのbazaar-jaに書き込んでください。
何度も更新ボタンを押さないといけないというのは、 '?' アイコンが表示されるから
最新のステータスを見るために押すのか、それとも何かの作業をした後で古い
ステータスが表示されたままなのか・・・両方かな。

個人的にはステータスが '?' のときに幾つかのメニューが表示されないのが一番の
問題と思ってるのですが、いつでも最新のステータス見たいですか？
いつでも最新の状態を見せようとすると、今の設計のままだとバックグラウンドで
動かしてるキャッシュプロセスの方が重くなってしまうから、なんとかしないとなぁ。

0818デフォルトの名無しさん

2009/09/29(火) 01:54:54

え？

0819デフォルトの名無しさん

2009/09/29(火) 02:07:41

プロファイラで分析してキャッシュプロセス高速化するしかなくね?

0820デフォルトの名無しさん

2009/09/29(火) 02:21:16

>>819
ファイルアクセスに時間かかってる気がする。
最適化してもたいして速くならないんじゃないかなぁ。

0821デフォルトの名無しさん

2009/09/29(火) 05:53:16

TortoiseBZRをエクスプローラでなくX-Finderで使うと
何もない場所で右クリックしたときのメニューがおかしい
アイコンの並び替えが、途中に混ざる

ファイルを右クリックした場合は問題ない

X-Finder側の問題？

0822デフォルトの名無しさん

2009/09/29(火) 08:34:28

x-finderは挙動が怪しい時があるね

0823817

2009/09/29(火) 10:36:00

ステータスチェックって、bzrの本体にやらせてるけど、多分、最新リビジョンから
取り出したファイルとディスク上のファイルを普通に比較してるんだと思う。

NTFSって、ファイルのCRCか何かをファイルの中身を読まないで取得することって
できるんだっけ？できるんだったら、それ使って独自の高速化が考えられるかも。

0824デフォルトの名無しさん

2009/09/29(火) 11:08:01

割切ってタイムスタンプだけ見るとか

0825デフォルトの名無しさん

2009/09/29(火) 11:12:05

どうでもいいけど、各論は各ツールのスレでお願いしたい。

0826820

2009/09/29(火) 11:26:10

>>823
TortoiseHg開発者(というかpatch contributor)です。
TortoiseHgでアイコンオーバーレイを現状のC++ではなくPythonで実現している頃、
そのあまりの遅さにコミットダイアログのファイル一覧に持たせるアイデアがありました。
つまり、ファイル一覧をWindowsエクスプローラのようなツリービューにしてしまって、
そこにファイル状態を示すアイコンをオーバーレイしよう、という感じです。

このアイデアは忘れ去られつつありますが、C++実装の今でもまだ利点があります。
まず巨大リポジトリではアイコンオーバーレイが遅くて使い物にならないので、
アイコンオーバーレイの機能をオフにしている人にとっては有効。
加えてアイコンオーバーレイの空きスロット問題が起きた時のフォールバックとして有効。
みんながTortoiseSVNのTortoiseOverlaysを使えばこの問題はほぼ回避できるのですが、
TortoiseOverlaysを利用していないアプリがあるとスロットが占有されてしまいます。
あとWindows 7とかではWindows自体がリザーブしてるスロット数がXPより多いとかで
空きスロット問題が再発してたりもします。

おそらくこのあたりを考慮して(開発リーダー)SteveのTODOリストには項目が残っていて、
このissueもopenなままになっています：
http://bitbucket.org/tortoisehg/stable/issue/2/status-dialog-tree-view-using-overlay

ただ、これが次期0.9で実現される可能性はかなり薄いですが・・・。

> NTFSって、ファイルのCRCか何かをファイルの中身を読まないで取得することって
> できるんだっけ？できるんだったら、それ使って独自の高速化が考えられるかも。

残念なことにチェックサムは常に0だそうな・・・
http://iss.x0.com/software/useful/filesystem.html

0827817

2009/09/29(火) 13:19:16

>>826
ええっと、Twitterでつながってる人ですよね。その節はお世話になりました。
空きスロット問題は悩ましいですね。いまさらTortoiseSVN開発者に
"LockedなんていらないからUnversionedアイコン優先しろ！"とか言えない。

TortoiseBZRが提供している機能は基本的にシェル周りだけで、
コミット画面等はQBzrに丸投げしてます。
アイコンオーバーレイをオフにして、コンテキストメニューはコンテキストに依存しないで
常にフル表示するオプションがあるといい気もしますね。

0828デフォルトの名無しさん

2009/09/29(火) 15:49:57

>>826-827
>>825

0829名無し募集中。。。

2009/09/29(火) 17:06:09

まあ出会いがある事は良い事じゃないか
やりすぎなければね

0830デフォルトの名無しさん

2009/09/29(火) 19:15:28

人との出会いは大切にしたい。
と、ぼっちの俺はいつも思ってる。｡･ﾟ･(ﾉД`)･ﾟ･｡

0831デフォルトの名無しさん

2009/09/30(水) 04:07:45

異なるバージョン管理ツールの開発者が似た機能について語り合ってるのは
スレタイにふさわしいと思うぞ。

0832デフォルトの名無しさん

2009/09/30(水) 08:36:06

>>779
できない
他のユーザーがチェックアウト中です
ってメッセージが出て編集できない
アド民の人に複数ユーザで使えるようにチェック入れてもらうしかない

0833826

2009/09/30(水) 13:43:54

>>827
> ええっと、Twitterでつながってる人ですよね。その節はお世話になりました。

いえいえ、こちらこそPythonの参照関連のアドバイスは本当に助かりました。

> 空きスロット問題は悩ましいですね。いまさらTortoiseSVN開発者に
> "LockedなんていらないからUnversionedアイコン優先しろ！"とか言えない。

たしかに。ぶっちゃけいらないアイコンの方が多いんですよね。

> TortoiseBZRが提供している機能は基本的にシェル周りだけで、
> コミット画面等はQBzrに丸投げしてます。

あ、そうなんですか。
となるともしやるならQBzrに相談が必要ですねぇ。面倒だ。

> アイコンオーバーレイをオフにして、コンテキストメニューはコンテキストに依存しないで
> 常にフル表示するオプションがあるといい気もしますね。

その機能は是非THGにも欲しいですね。
というより、現状のTHGのコンテキストメニューはあまり賢くないんです。
コンテキストに依存しないオプションの前にもっとコンテキストに依存する方を改善すべきかもw

0834デフォルトの名無しさん

2009/09/30(水) 22:42:45

開発者は有意義に議論してくれ
素人は指加えてROMってるわ

0835デフォルトの名無しさん

2009/10/01(木) 10:14:07

Windowsでまともに使えるモノにしてからリリースしろアホ

0836デフォルトの名無しさん

2009/10/01(木) 10:36:33

>>835
バグレポート書かないで文句だけ言うのは建設的じゃない。
まともにつかえなかったのはhg?bzr?TortoiseHG?TortoiseBZR?
具体的な問題点は何？

0837デフォルトの名無しさん

2009/10/01(木) 10:38:39

えーマジWindows？　キモーイ　Windowsが許されるのは小学生までだよねー

0838デフォルトの名無しさん

2009/10/01(木) 10:44:40

>>836
・TortoiseGit UTF-8未対応な件。
cygwin 版git(UTF-8 DLL導入済み)において、マルチバイトファイル名を使うと正しくアイコン、ファイル名が表示されず、コミット不能。

・TortoiseHG
結局、マルチバイトファイル名使うには何がいいの？

0839デフォルトの名無しさん

2009/10/01(木) 11:46:16

Windowsって大変なんだな...

0840デフォルトの名無しさん

2009/10/01(木) 11:48:43

Windowsが大変なんじゃない、Windows対応が大変なんだ。

0841デフォルトの名無しさん

2009/10/01(木) 11:58:15

>>840
マルチバイト対応が大変なんだろ。
THGだって、日本語使わなきゃまともに動くし。

0842デフォルトの名無しさん

2009/10/01(木) 14:42:45

マルチバイトファイル名なんか使うやつはばかです

0843デフォルトの名無しさん

2009/10/01(木) 14:43:05

ソースの日本語コメントがdiff窓で文字化けしてて読めない
そんなwindows

0844デフォルトの名無しさん

2009/10/01(木) 16:39:24

Windowsにこだわるやつってなんなの? 死ぬの?

0845デフォルトの名無しさん

2009/10/01(木) 16:49:39

Windows対応が大変というより、最初UNIXべったりで作ったのをそれ以外に持っていくのが大変なんだと思うよ。
今はWindows以外は全部UNIXになってしまっているからWindowsが叩かれるけど、OS/2やBeOSが生き残っていたら話は違ってたと思う。

0846デフォルトの名無しさん

2009/10/01(木) 16:51:58

異端児Windowsｶﾜｲｿｽ

0847デフォルトの名無しさん

2009/10/01(木) 17:15:23

>>836
Windowsユーザは、新しいバージョンがリリースされるたびに評価し落胆し疲れ果ててるんだよ・・・

0848デフォルトの名無しさん

2009/10/01(木) 17:21:35

>>845
つ Haiku

0849デフォルトの名無しさん

2009/10/01(木) 17:59:35

>>845
＞今はWindows以外は全部UNIX
ところが、総量では逆転。ｗ

0850826

2009/10/01(木) 22:19:12

>>838
> ・TortoiseHG
> 結局、マルチバイトファイル名使うには何がいいの？

Windowsだけで運用するという条件付きですが、最新のwin32mbcsと
TortoiseHg 0.8.2で動作確認できています。経緯はここ：
http://groups.google.com/group/mercurial-ja/browse_frm/thread/2a25b275f631cea3?hl=ja#

MLにある通り、Mercurial 1.3.1に含まれているwin32mbcsは古いので、
今すぐ使いたい場合は最新のwin32mbcsに差し替えてください。
「そういうのよくわからない」って場合は次のリリースまで待ってください。
たぶんMercurial 1.3.2のリリースと共にTortoiseHg 0.8.3も出ますので。

それと日本語関連の情報はWikiにもまとめてあります：
http://bitbucket.org/kuy/thg-ja/wiki/Japanese

0851デフォルトの名無しさん

2009/10/01(木) 22:44:58

>>849
なにその中国人思考

0852デフォルトの名無しさん

2009/10/02(金) 22:01:31

> Windowsだけで運用するという条件付きですが、

これがダメ。もうバケバケになったログを解読するのはいやだお

0853デフォルトの名無しさん

2009/10/02(金) 22:19:35

また馬鹿なbzr厨が現れたのかwww
邪魔だからここに来るな

0854デフォルトの名無しさん

2009/10/02(金) 22:24:58

必死だな

0855826

2009/10/02(金) 23:23:56

>>852
> これがダメ。もうバケバケになったログを解読するのはいやだお

ログ？コミットログのこと？

0856デフォルトの名無しさん

2009/10/03(土) 01:22:16

>>855
log -v でコミットログがutf-8で、ファイル名がcp932に混ざったりしない？
ひどい例だと、古いCVSリポジトリにutf-8とeucとcp932のファイル名が
混ざってたなぁ。

0857826

2009/10/03(土) 06:28:23

>>856
うーん、最近のutf-8がデフォのLinuxでコミットしていて、Windowsからも
そのリポジトリにコミットすると確実に混ざるはずです。

「あれ、相互運用できちゃってるよ？」っていう例もあるんですが：
http://twitter.com/wtnabe/status/3977926464
http://twitter.com/wtnabe/status/3978688525
http://twitter.com/wtnabe/status/3979217435

ただ、リポジトリ内でエンコーディングがバラバラってのは
さすがにbzrでもsvnでも同じような状況になる気がするんですが・・・。

0858デフォルトの名無しさん

2009/10/03(土) 06:31:49

>気がする
>気がする
>気がする

0859デフォルトの名無しさん

2009/10/03(土) 10:44:40

>>857 気のせいｗ
svnとbzrはファイル名とかコミットログはunicodeで保存するから、それは平気。

0860デフォルトの名無しさん

2009/10/03(土) 11:21:09

svnはもうその辺数年前に通り過ぎた道

>>850
fix-utf8でなくて、win32mbcs？
win32mbcsてマルチバイドのフォルダとかファイル名大丈夫だっけか…？？
って、自分で確認しないと菜・・・

>>847
俺もういやになった
面倒だから、Tortoise系みすてて、cygwin gitでUTF-8で突っ込みまくってるｗｗｗ
git statusとかでも、ファイル名が数字のコードででてきてワロスｗ

0861デフォルトの名無しさん

2009/10/03(土) 11:25:45

みんなそんなに日本語のファイル名付けるん？

>>860
CygwinってUTF-8ダメなの？

0862デフォルトの名無しさん

2009/10/03(土) 12:02:46

>>861
UTF-8 Cygwin と、Cygwin-1.7(+LANG=ja_JP.UTF-8)ならおk。
あと、ソースにはさすがに日本語ファイル名付けないけど、
「01.詳細仕様書/テーブル定義.xls」とかはふつーにあるわ。

0863デフォルトの名無しさん

2009/10/03(土) 12:47:41

>>862
ファイル名にスラッシュを入れても大丈夫なの?
unixでどうなるんだろ。

0864826

2009/10/03(土) 12:49:37

>>859
> >>857 気のせいｗ
> svnとbzrはファイル名とかコミットログはunicodeで保存するから、それは平気。

ああ、もうsvnも完全にunicodeなんですか。知りませんでした。
適当なこと言ってしまってすみません。

0865826

2009/10/03(土) 13:07:36

>>860
> >>850
> fix-utf8でなくて、win32mbcs？
> win32mbcsてマルチバイドのフォルダとかファイル名大丈夫だっけか…？？
> って、自分で確認しないと菜・・・

fixutf8をフォークしたfixutf8-jpは改良が断念されました。
http://groups.google.com/group/mercurial-ja/msg/5b6952f29f8ae561

win32mbcsが唯一今のところ問題のない手段です。Windows限定で。
Linuxとの相互運用の場合は確実な手段がありません。

コマンドプロンプトでログが化けても、TortoiseHgではちゃんと表示できる
のは、TortoiseHgが正しくエンコードできるまで複数の文字コードで試すからです。
この場合、コミットログがShift_JISでファイル内容がUTF-8でも表示されます。

0866デフォルトの名無しさん

2009/10/03(土) 13:37:50

ファイル名は最悪我慢するにしても、コミットのメッセージがうっかりミスでSJISとEUC混在とかなったら死ねる
DVCSだと過去のメッセージの書き換えとかできなそうだし。

0867デフォルトの名無しさん

2009/10/03(土) 13:50:48

bzrもhgも、コミットログを設定されたエンコーディングでデコードしてutf-8にエンコードするね。
でも、うっかりcp932の設定のままutf-8の文字列がcp932と勘違いされてデコードされ、
デコードエラーにならずにutf-8にエンコードされて格納されてしまったことが一度だけある。
cp932こえーわ。

0868デフォルトの名無しさん

2009/10/03(土) 13:56:44

>>862
んじゃUTF-8 Cygwinなら、UTF-8のファイル名は化けないのかな。
UTF-8つってもMacの人が混ざると濁点がおかしくなりそうだけど…

>>866
ターミナルなら混ざってても | nkf -w とかやればそれっぽく見れるんだけどねぇ

0869デフォルトの名無しさん

2009/10/03(土) 21:04:55

>>863
すまん、そいつはディレクトリセパレータだ。
単に日本語ディレクトリ名 + 日本語ファイル名の例を出したかっただけなんだ。

>>868
yes. Macに関しては試したことがないからわからん。お察しの通りのような気がするけど。

ただ、ファイル名がUTF-8のときにファイルの中身がShift_JIS/CP932だと、差分を見たときなどに泣ける。(テキストのドキュメントとか)

0870デフォルトの名無しさん

2009/10/03(土) 21:31:57

結局、Unicodeを採用すると言いつつnormalizationで手を抜いてるんだなー。

0871デフォルトの名無しさん

2009/10/03(土) 22:05:16

bzr付属のdiffが色分けしてくれて便利だ
しかし、その画面のままここだけマージしてほしい、他はだめとかしてくれないのね
emacsからすればその辺便利なのかな

0872デフォルトの名無しさん

2009/10/03(土) 23:38:17

>>870
手を抜いているというか、手が回ってない感じだな。
svnだって対応するのに時間がかかったんだ、許してやってくれ。
https://bugs.launchpad.net/bzr/+bug/172383

0873デフォルトの名無しさん

2009/10/04(日) 01:21:04

>>865
fixutf8-jpでも駄目な条件を知っていれば問題ないだろ。

0874デフォルトの名無しさん

2009/10/04(日) 04:19:20

Eclipse環境(on Windows)でgitを試してみようかと思ってるんだけど、
msysgitとかeclipse用のgitプラグインとか、現状で完成度はどんなもんなんだろう。

0875デフォルトの名無しさん

2009/10/04(日) 16:42:10

>>865
> fixutf8をフォークしたfixutf8-jpは改良が断念されました。
マジ！？期待してたのに駄目になったのかよ！

> win32mbcsが唯一今のところ問題のない手段です。Windows限定で。
> Linuxとの相互運用の場合は確実な手段がありません。
Windows限定ｗｗｗ
いや、駄目だろそれはｗ
OSSなんかの開発で(bitbucket.orgに突っ込んだ場合でもいいけど)
Linuxとか他の環境と相互にできなかったらあかんわー

hgは大変だな・・・コミットするのはマズイけど、
表示だけはTortoiseHgでできる？ということでいいんでしょうか？
確かに前試した時もマルチバイト非対応時のときも見れてはいた気もします。

このとき逆にhgは(TortiseHgがね)マルチバイト対応だと思ってWindowsから突っ込みまくった、痛いリポジトリが残ってるんだよな・・・

0876デフォルトの名無しさん

2009/10/04(日) 16:46:29

>>865のmercurial-jaのログ見たら
fixutf8-jpレベルではムリ、本家を弄れば可能性ある、ってことなのね。
>>875でちょっといいすぎてしまった、スマソ

0877デフォルトの名無しさん

2009/10/04(日) 17:20:56

fixutf8-jpはTortoiseHgとの連携とリポジトリパスに日本語を含む場合のみ対応していない。
TortoiseHgとの連携に関してはfixutf8-jpを改良したやつがある。
リポジトリパスはプラグインを読み込む前に、リポジトリパスを設定しているから対応できない。
0x5cを含んでなくてもトランザクションファイルを作成するときにopenを使っているので動かない。

0878デフォルトの名無しさん

2009/10/06(火) 15:25:55

Hgは、コードよりも開発者の頭の中をハックしなくちゃね・・・・
SVNなんて設計段階から、Unicode前提だったのに。

まぁ、Pythonで書き始めたときにPythonのUnicodeサポートが弱かったのが
原因なんだろうなぁ・・・・

Python3以降に開発されてるCoolなバージョン管理システムないのかな？

0879デフォルトの名無しさん

2009/10/06(火) 16:29:53

つか、クライアントアプリは、ネイティブアプリにしてくれったら！

0880デフォルトの名無しさん

2009/10/06(火) 19:47:40

Python 2.xのUnicodeは正直クソだと思う

0881デフォルトの名無しさん

2009/10/06(火) 19:53:47

BazaarはPython2でもUnicodeベースで動作するんだから、Pythonの問題じゃないだろ。
ファイル名をバイト列として扱うのかUnicode文字列として扱うのかは単なる設計ポリシーの問題だ。

クロスプラットフォームのことを考えていろいろな問題に立ち向かうならUnicode、Posixの
世界に引きこもっていろいろな問題から逃げるならバイト列。

0882デフォルトの名無しさん

2009/10/06(火) 21:01:40

>>881
unicodeの時点でTRONコードを扱えないわけで
どのへんで妥協するかの問題だな。生きていく上では重要だけど。

0883デフォルトの名無しさん

2009/10/06(火) 21:06:04

Pythonの問題じゃない
Unicodeは正直クソ

0884デフォルトの名無しさん

2009/10/06(火) 23:45:58

Python使ってるのが糞

0885デフォルトの名無しさん

2009/10/07(水) 00:11:01

全く論理的な根拠を示さずPythonを攻撃しているのは大抵Ruby厨。

0886デフォルトの名無しさん

2009/10/07(水) 00:14:24

Perl厨「計画通り！」

0887デフォルトの名無しさん

2009/10/07(水) 00:18:27

Java厨「通りがかりです」

0888デフォルトの名無しさん

2009/10/07(水) 01:37:23

実際rubyとpython両方使ってるとpythonはいい
食わず嫌いでrubyしかやらないのはもったいない

0889デフォルトの名無しさん

2009/10/07(水) 01:38:54

pythonのどの辺がRubyよりいいの？

0890デフォルトの名無しさん

2009/10/07(水) 01:52:59

Rubyのどの辺がpythonよりいいの？

0891名無し募集中。。。

2009/10/07(水) 02:34:42

時と場合により両方使えって事ですよ

0892デフォルトの名無しさん

2009/10/07(水) 08:54:34

そろそろスレタイ見ような

0893デフォルトの名無しさん

2009/10/07(水) 14:04:13

日本語spam filterがrubyで書かれてるの見て、日本語処理はrubyなのかなと思うこともある

0894デフォルトの名無しさん

2009/10/07(水) 14:15:18

Rubyに特別spam filter書きやすいような日本語対応が入っているわけじゃないし、
いい加減スレチだからLLスレにでも行ってくれ。

0895デフォルトの名無しさん

2009/10/07(水) 14:18:31

言語的にVCSを作るには全く向いていないんだよ、Rubyは。
もしHgやGitを淘汰できるVCSがRubyでできたら俺は切腹してやってもいい。

0896デフォルトの名無しさん

2009/10/07(水) 16:41:20

本体がPythonで書かれてると勘違いするアホまで登場する始末

0897デフォルトの名無しさん

2009/10/07(水) 22:09:23

本体って何の本体？

0898デフォルトの名無しさん

2009/10/07(水) 22:43:41

Mercurialはほぼpythonだろ.

0899デフォルトの名無しさん

2009/10/08(木) 06:53:51

ある意味yumもバージョン管理システムな訳で

0900デフォルトの名無しさん

2009/10/08(木) 06:58:15

>>899
それはほんとにある意味だね

0901デフォルトの名無しさん

2009/10/08(木) 08:32:47

え？MercurialってほぼPythonなの？
糞過ぎるわ

0902デフォルトの名無しさん

2009/10/08(木) 08:56:55

>>895
>言語的にVCSを作るには全く向いていないんだよ、Rubyは。
何を根拠にいってるんだ？Rubyに対してかれはどんなトラウマを抱えているのだろう。

>もしHgやGitを淘汰できるVCSがRubyでできたら俺は切腹してやってもいい。
今、githubの連中がGitをまるごとRubyに移植中だから、完成したらWindowsでGitを使う時の定番になるだろう。Mercurial死亡フラグ。
そのときがきたらぜひ切腹してくれ。

0903デフォルトの名無しさん

2009/10/08(木) 09:43:55

>>902
マイナーバージョン間でも互換性がないとかなんとか

0904デフォルトの名無しさん

2009/10/08(木) 09:56:00

>>903
それはVCSはおろか中長期的に使われるあらゆるツールに向いてないだろJK

0905デフォルトの名無しさん

2009/10/08(木) 09:57:12

git を ruby で実装って何の意味があるんだろう？処理が速いことが重要なんじゃなかったのか git は……

0906デフォルトの名無しさん

2009/10/08(木) 10:27:49

>>905
Windowsで使うときにPosix互換レイヤが必要ないとかシェルやPerlが必要ないとか。
PythonでもdulwichというPure Python（一部は速度のために拡張モジュールあり）の
git リポジトリライブラリがあって、それを使ったbzr-gitが開発中。
既にWindowsで bzr branch git://foo.com/bar.git できる。

0907デフォルトの名無しさん

2009/10/08(木) 11:46:10

頼むから、C/C++で実装してくれ

0908デフォルトの名無しさん

2009/10/08(木) 12:37:23

gitにC++はおそらくない、というのは既知。

0909デフォルトの名無しさん

2009/10/08(木) 16:18:08

>>904
だからWeb専用言語から脱却出来ないんじゃね？
PHP4なみに変更あるからな

0910デフォルトの名無しさん

2009/10/08(木) 17:13:13

>>909
噂では聞いてるが本当にそんなに変わるの？
マイナーアップデートですら互換性ないとか言ったらWeb専用でも使いたくない。

0911デフォルトの名無しさん

2009/10/08(木) 17:26:08

pythonもrubyも使うが、
rubyは標準ライブラリがpythonより多いので、そう感じるだけでは？
基本的なメソッドの上位互換性で言ったら、pythonの方が差異が大きいと思う。

0912デフォルトの名無しさん

2009/10/08(木) 17:27:24

>>901
たとえばこのバージョンのRailsではこのRubyじゃないと動かないって縛り結構あるよ

0913デフォルトの名無しさん

2009/10/08(木) 17:29:55

pythonは再利用が多いけど
rubyは書き捨てが多いな
なんでだろ

0914デフォルトの名無しさん

2009/10/08(木) 17:34:17

>912

0915デフォルトの名無しさん

2009/10/08(木) 17:46:26

互換がしっかりしてるのなんてメジャー言語だと逆にCとJavaとPerlくらいだぜ

0916デフォルトの名無しさん

2009/10/08(木) 18:18:43

このバージョンのVCSはこのバージョンの○○では動かない

0917デフォルトの名無しさん

2009/10/08(木) 18:30:22

>>907
C/C++で書くと、Subversionみたいに成熟度が上がるまでにすごく時間がかかるぞ。
速度が必要な部分だけCで、それ以外はPythonというのは、Linuxの世界では
かなり浸透しているんだけど、何か問題ある？

0918デフォルトの名無しさん

2009/10/08(木) 18:34:26

>>915
それだったらC++もいれろ。

0919デフォルトの名無しさん

2009/10/08(木) 18:36:40

>>918
C++は入れなくていい。

……っつか、コンパイルする言語だと、非互換性はあんまり意味ないんだよな。
実行ファイル作ってしまえば関係ないので。

0920デフォルトの名無しさん

2009/10/08(木) 18:42:09

>>919
dynamic link

0921デフォルトの名無しさん

2009/10/08(木) 19:27:54

言語レベルだけの互換性を考えても仕方ない。
HTTPリクエストするには？ディレクトリツリーをたどるには？ファイルの属性を取得するには？

Pythonを使うと、たとえばPythonのAPIだけでは足りないときにもctypesが標準ライブラリに
入っていたりして、クロスプラットフォームアプリをすごく作りやすい。

0922デフォルトの名無しさん

2009/10/08(木) 19:47:47

日本語環境で実用レベルで使い倒せるものが出てくるなら言語なんて何でもいい

0923デフォルトの名無しさん

2009/10/08(木) 19:53:20

emacs lispならどんな言語でもいける。

0924デフォルトの名無しさん

2009/10/08(木) 20:41:36

MozillaのHg移行後も長いこと揉めてたBugzillaのDVCS、「圧倒的多数の支持」によってBazaarに決定

http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/0d275b79724cab9a
Mercurial嫌われすぎﾜﾛﾀ

0925デフォルトの名無しさん

2009/10/08(木) 20:47:59

最近の動静を見てると、Bazaarの方が伸びそうな気はする。
名前が格好悪いのが何とかなれば使いたいレベル。

0926デフォルトの名無しさん

2009/10/08(木) 20:51:32

ばざぁｗ

0927デフォルトの名無しさん

2009/10/08(木) 21:44:21

心の中で、ござーる、と呼んで勝手に親しんでいるのは俺だけじゃあるまい

0928デフォルトの名無しさん

2009/10/08(木) 21:55:49

ばざーるでござーる、とか突然浮かんで困ったことは以前あった

0929デフォルトの名無しさん

2009/10/08(木) 22:18:58

会社のプロキシがWebDAVを通さなくて、httpでもsvnのチェックアウトがコケるんですが、
回避策を知ってる人がいたら教えてください。

0930デフォルトの名無しさん

2009/10/08(木) 22:21:11

hgやbzrならWebDAVではない単なるPOSTなので、通る……たぶん。

0931デフォルトの名無しさん

2009/10/08(木) 23:52:01

httpsなら単なるトンネルだからWebDavも通してくれるんじゃね？

0932デフォルトの名無しさん

2009/10/08(木) 23:58:50

切腹宣言とか勇者すぎ。逃げるなよー。

0933デフォルトの名無しさん

2009/10/09(金) 00:12:40

>929
https なら通るよ。
または ssh で隧道を掘る

0934デフォルトの名無しさん

2009/10/09(金) 00:16:55

>>933
具体的に言うとGoogle Codeにホスティングしているプロジェクトのレポジトリなのですが、
あれってdeveloper以外でもアクセスする方法はあるんでしょうか。
何度か試してみた感じ、パスワードを要求されてしまうようです。

0935デフォルトの名無しさん

2009/10/09(金) 00:21:47

Google Codeは、http=読み取りのみ、https=書き込み権あり、の使い分けだからなー。
……ノーマルhttpでも個々のファイルは見えるので、wgetで取っちゃえば？

0936デフォルトの名無しさん

2009/10/09(金) 00:26:09

>>935
それしかないかもしれないですね。
そのプロジェクト、svn:externalsでよそのレポジトリから大量にコードをインポートしてくる
みたいなのですが、暇を見つけてぼちぼち落とすとします。。

0937デフォルトの名無しさん

2009/10/09(金) 05:28:17

ええええ～
今の流れはbzrなん？
hg使い始めたばかりなのに・・・

0938デフォルトの名無しさん

2009/10/09(金) 07:14:07

いや、bzrが微妙に伸びてるけどgitの方が主流だよ。
hgは知らね。

0939デフォルトの名無しさん

2009/10/09(金) 07:18:34

hgはじめました

0940デフォルトの名無しさん

2009/10/09(金) 09:06:36

svnが主流だよ。gitは3%くらいのシェアをとっててbzrは1%だけど、bzrが追い上げてきてる。

0941デフォルトの名無しさん

2009/10/09(金) 13:03:48

仕事で日本語ファイル名を使うならSubversionが有利だと思う

0942デフォルトの名無しさん

2009/10/09(金) 13:14:20

伸び的には git だと思うなぁ

と各自出典を出さずに話すのであった

0943デフォルトの名無しさん

2009/10/09(金) 13:55:58

git 日本語ファイルダメなんでしょ?

と、いいつつ Mercurial 使っているのであった。

0944デフォルトの名無しさん

2009/10/09(金) 14:15:29

rebaseが便利でhgからgitに移ったよ
bzrはどうなんだろ?

0945デフォルトの名無しさん

2009/10/09(金) 14:19:01

bzr-rebaseはあるけど、基本的にbzr-svnでしか使わないなぁ。
普通にマージしたほうがいい。

0946デフォルトの名無しさん

2009/10/09(金) 14:19:06

git は魅かれるんだけど
概念を覚えるのが面倒でなぁ
何かきっかけがないと

0947デフォルトの名無しさん

2009/10/09(金) 14:20:33

会社がWindows中心で動いてるのでSubversionですん

0948デフォルトの名無しさん

2009/10/09(金) 14:31:00

会社はWindowsだけど、ファイル名に日本語はないからgitですん

0949デフォルトの名無しさん

2009/10/09(金) 14:32:40

うちではSubversionとは言わないな
TortoiseSVNと呼ばれている

0950デフォルトの名無しさん

2009/10/09(金) 14:35:01

うちでは TortoiseSVN が Subversion とか SVN とか呼ばれてる。
わからんでもないんだが、見聞きするたびに気持ち悪い。

0951デフォルトの名無しさん

2009/10/09(金) 14:56:47

うちではBzrと言えばbzrのことで、BazzarといえばTortoiseBzrのことだ。

0952デフォルトの名無しさん

2009/10/09(金) 15:00:37

progit.pdfいいね。やっとgitがわかってきた。hgとの違いにびっくりだわ。ばざぁーはいいドキュメントある?

0953デフォルトの名無しさん

2009/10/09(金) 15:01:47

うちはCVSをたまにCSVというよ

0954デフォルトの名無しさん

2009/10/09(金) 15:51:15

>>917
速度が必要な部分までPython使ってるから文句言ってんだけど。

0955デフォルトの名無しさん

2009/10/09(金) 15:53:37

具体的にどこ?

0956デフォルトの名無しさん

2009/10/09(金) 17:14:05

>>953
単に間違ってるだけだろｗ

0957デフォルトの名無しさん

2009/10/09(金) 20:54:43

なんかみんな流されてない？
CVSで十分っしょ。

0958デフォルトの名無しさん

2009/10/09(金) 21:01:30

>>957
ありえねｗｗｗｗｗｗｗ

0959デフォルトの名無しさん

2009/10/09(金) 21:07:22

選択の基準は、フロントエンドの操作性だろやっぱり。

0960デフォルトの名無しさん

2009/10/09(金) 23:14:59

とりあえず、日本語ファイル名を封印する分には、
DVCSはどれも日本語環境でも大丈夫なのかな

0961デフォルトの名無しさん

2009/10/09(金) 23:16:48

お前ら技術者なら日本語言わないでマルチバイトって言ってくれ
ローマ字も日本語だ

0962デフォルトの名無しさん

2009/10/09(金) 23:22:58

マルチバイトといっても日本語が通るとは限らないんじゃね

0963デフォルトの名無しさん

2009/10/09(金) 23:54:30

>>961 ローマ字も日本語
ja_JP.asciiになるのかな？

0964デフォルトの名無しさん

2009/10/10(土) 00:44:40

>>960
コミットログとかもあるでよ。

0965デフォルトの名無しさん

2009/10/10(土) 00:49:04

言語と用字とエンコーディング

0966デフォルトの名無しさん

2009/10/10(土) 00:50:29

>>964
コミットログが大丈夫なのはどれ？

0967デフォルトの名無しさん

2009/10/10(土) 00:53:57

ファイル名・ログ両方ともbzr以外全滅じゃなかったっけ

0968デフォルトの名無しさん

2009/10/10(土) 01:00:30

bzrとsvnが大丈夫。

0969デフォルトの名無しさん

2009/10/10(土) 01:10:32

いや、DVCSだろ

0970デフォルトの名無しさん

2009/10/10(土) 14:19:46

>>953
あるあるｗ

0971デフォルトの名無しさん

2009/10/10(土) 15:19:59

クリアケースおわっとるわ。
インターフェース超最悪。
ほんとにバージョン管理できんのかこれ？
もうちょっと弄ってみるが。

0972デフォルトの名無しさん

2009/10/10(土) 15:32:57

bzrとsvnは大丈夫、他はヤヴァイ

0973デフォルトの名無しさん

2009/10/10(土) 15:34:01

うちは、CSV形式のことを延々とプロジェクト終了までCVS、CVSと言い放った上司がいてだな・・・
指摘しても直さないから、ｈ

0974デフォルトの名無しさん

2009/10/10(土) 16:02:58

最近clearcaseがクソだって話題が定期的に出るけど、使ってる人けっこう居るのかな？

俺は触ったことないけど、Wikipedia見たら
＞欠点
＞トランザクションがアトミックでない。
＞コードベースが古く、新規機能追加が遅い。
＞非常に複雑で、構成設定に注意を要する。
＞遅い。単純なコミットやチェックアウトが数分かかることも稀ではない。
って書いてあって引いた。業務上使わざるを得ないんだろうけど、同情するわ。

0975デフォルトの名無しさん

2009/10/10(土) 21:38:02

ｂｚｒはさくっとWindowsにインストールできるようになったの？

0976デフォルトの名無しさん

2009/10/10(土) 22:06:19

これ系のツールの総称ってVCSなの？RCSなの？
どっちが通りがいいんだろう。

0977デフォルトの名無しさん

2009/10/10(土) 22:16:58

>>976
RCSって名前のVCSはあるね。

0978デフォルトの名無しさん

2009/10/10(土) 22:17:59

RCSって固有名詞じゃなくて総称名詞として使われることなんてあるのか？

0979デフォルトの名無しさん

2009/10/10(土) 22:20:31

VCSか、あるいはSCM(Source Code Management) かな…
Software Configuration Managementだと違うレベルの話になる。

0980デフォルトの名無しさん

2009/10/10(土) 22:20:39

どっちもgoogleのトップには出てこないという

0981デフォルトの名無しさん

2009/10/10(土) 22:28:15

SVC

0982デフォルトの名無しさん

2009/10/10(土) 23:16:25

バ管ス

0983デフォルトの名無しさん

2009/10/11(日) 00:57:59

日本放送協会がNHKなんだから
バージョン管理システムはBKSだろ

0984デフォルトの名無しさん

2009/10/11(日) 01:51:52

版管理系統 HKKだろ

0985デフォルトの名無しさん

2009/10/11(日) 10:22:04

>>975
むしろwindows でインストールして使い始めるのはbzrが一番簡単だと思う

0986デフォルトの名無しさん

2009/10/11(日) 10:39:22

>>975
Ubuntuインストールするのが一番手っ取り早いと思う

0987デフォルトの名無しさん

2009/10/11(日) 10:46:39

>>985
え？svnが一番簡単じゃないの？

0988デフォルトの名無しさん

2009/10/11(日) 10:49:14

使い始める場合だと、リポジトリを作らないといけないsvnよりbzrの方が簡単だろうな。
昔、svnで file:///C:/ のスラッシュがひとつ足りなくてハマッた覚えがある。

0989デフォルトの名無しさん

2009/10/11(日) 10:58:47

tsvnはリポジトリは右クリックですぐ作れるけど

bzrはリポジトリが無くてもいいの？

0990デフォルトの名無しさん

2009/10/11(日) 11:43:06

file:

0991デフォルトの名無しさん

2009/10/11(日) 12:03:01

>>989
bzrでもhgやgitでも、純粋にバージョン管理したいだけならリポジトリ&ブランチ＆作業ツリーを
一箇所にまとめられるから、一度で全部作れる。
svnはリポジトリを作成してからチェックアウトしないといけない。

0992デフォルトの名無しさん

2009/10/11(日) 15:20:08

バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/

0993デフォルトの名無しさん

2009/10/11(日) 16:16:18

リポジトリが同じ場所にあるってことは、ディレクトリごと消してしまったら履歴ごと消えるというわけで……
不安じゃない？
皆さんどんな用途で使ってる？

0994デフォルトの名無しさん

2009/10/11(日) 16:20:18

>>988
TortoiseSVNで普通のパス指定できるようなバージョンアップってしないのかね。
あれ面倒なんだよな。

>>993
ソースコード管理とは別に毎日robocopyやpdumpfsでバックアップすればいいんじゃね。

0995デフォルトの名無しさん

2009/10/11(日) 16:24:13

全部dropboxに突っ込んどくとか？

0996デフォルトの名無しさん

2009/10/11(日) 16:30:24

>>994-995
いや、バックアップもするなら最初から履歴付きのバックアップツール使えばいいと思うんだ。
push/pop先無しの単独リポジトリということは、他のPCと共有しないものを入れるということで
設定ファイルや個人的なドキュメントが主用途かなあ？と想像するのだけど
それならOSにはじめからあるバックアップと復元センターやTimeMachineの方が優秀な気がして。

0997デフォルトの名無しさん

2009/10/11(日) 16:42:05

そらローカルに置くなら個人用だろ。
別にそれしかできないわけじゃないし。

バージョン管理とバックアップは別もんだし
併用しちゃいけないなんて縛りはどこにもない。
保険は多い方がいい。

0998デフォルトの名無しさん

2009/10/11(日) 17:08:52

>>991
bzrはいつブランチをまとめれるようになったんだ？

0999デフォルトの名無しさん

2009/10/11(日) 17:12:41

>>998
bzr-local-branchesプラグインが出来てから

1000デフォルトの名無しさん

2009/10/11(日) 17:15:58

（ * ）ここ

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。