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

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

●関連スレ
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/

●関連サイト
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

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

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

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

すまん、URLだけ間違えた

ci -m '乙'

＼
　 ヽ、　　　_ノ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　｀'ｰ '´
　　　　　○
　　　　　　Ｏ
　　　　　　　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、

ここ即氏判定あり？

テンプレ追加

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

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

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

svnにしとけ

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:

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

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

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

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

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 を使っているのですが、
何かほかに設定などが必要なのでしょうか？

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

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

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

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

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

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

>>18
Windows なら TorotiseSVN 最強。

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

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

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

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

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

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

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

>>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
というエラーは表示されてしまいます。

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

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

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

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

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

なにそれ

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が使えないのでしょうか？

いいかげんにして

誰も私 わかってくれない

もういやよ、こんなの

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

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

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

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

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

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

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

おつかれさま

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

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

つ git-svn

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

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

>>40
hgsubversionとかどうで(略

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MS専用 UTF規格？

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

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

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

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

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

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

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

MS規格ってなんなの？

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

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

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

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

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

>>79
ｋｙ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>86
record extension 使えばできる

>>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涙目( ´･ω･`)

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

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

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

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

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

ちょいと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でカラー表示強制するコマンドラインオプションを探していたのですが、見当たりませんでした…

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

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

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

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

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

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

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

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

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

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

>>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
あざーっす！

>>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

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

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

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

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

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

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

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

root
|
+-config_for_A
+-config_for_B
+-common_sources

ありがとうございます。

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

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

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

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

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

>>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

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

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

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

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

>>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
までおそくなった。

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

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

レス遅れた。サンクス

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

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

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

>>118
>hgsubversion

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

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

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

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

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

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

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

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

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

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

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

w
|
o |
| |
|/
@
|

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

>>128
ずれた
w working dir
|
| o tip
| |
|/
@ parent of working dir
|

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

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

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

>>133
Perfoce必死すぎｗｗｗ

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

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

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

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

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

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

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

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

ロックしろよ

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

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

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

uze-yo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おーでかーけでーすかー

レレレのレー

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

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


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

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

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

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

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

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

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

>>172
あるよ

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

ごめん、途中ダッタ。

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

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

こんな方法もあるけど、自己責任で。特に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ブランチを追加

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

reset → amend → rebase

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

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

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

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

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

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

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

>>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できないと思うよ。

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

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

>>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 ってやるほうが安全だとおもうけど

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

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

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

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

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

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

>>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
これか。

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

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

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

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

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

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

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

bzrじゃね?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

みんな、もちつけ。

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

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

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

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

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

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

>>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だとこういう迷惑な仕様
になってるんだよね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

alias esr=bzr

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

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

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


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

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

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

>>235
utf-8 cygwinを使えばgitもW系API使うな。
msys git は無理だけど。

実用レベルに達したWindows向けGitクライアント「TortoiseGit」でGitを始めよう
ttp://sourceforge.jp/magazine/09/06/19/0340248

hg派としてはとてもうらやましいです

>>238
TortoiseHg って、まだダメダメだったりするん？

>>238
うーん...
> 　TortoiseGitでは内部的にmsysgitを使用している。そのため、日本語ファイ
> ル名の扱いも現状ではそれに準じたものとなり、ファイル名はシフト
> JIS（CP-932）で保存される。

結局ファイル名はバージョン管理どれ使うにしてもascii使え、
ascii使えば機能は大差無いから好きなの使っとけってこと？

Mac使えば糞面倒な事やらなくてもTimeMachine一発なのにな

>>242
君のは単なる勘違い
他のMacユーザーに迷惑だから認識を改めてくれ

>>238
Windows上だとhgのがずっと筋がいいから遠からず追いつくと思う。
win環境でgitからhgに変えて速いのにびっくりした。

Tortoiseの完成度
Hg > Git > Bzr

Bzr がんばれ
応援してる







Git使いだけど。

>>246
とりあえず日本語ディレクトリ名がだめなのは、bzr自体がUnicodeコマンドラインオプション
受けとるようになったから、TortoiseBZRのバグトラッカーにそれを使うようにするパッチを
置いといた。
それ以外に何か足りてないのがあれば、言ってくれたら暇な時に対応するよ。

今、 BzrExplorer ってのがハイペースで開発されてる。
Tortoiseは重くなるのがいやだからこっちに期待してる。

Tortoiseは統合してくれないかなぁ…

>>238
飛ばし記事乙
何が、実用レベルだ。

>>240の問題があり、>>237しないといけなくて、
TortoiseGitではUTF-8 cygwinは微妙に対応が変
UTF-8日本語ファイル名は化けたり、オーバーレイアイコンが付かなかったりするする

>>242
何が一発なの？MacでWindowsの日本語ファイル周りの問題を解決できるの？

正直、もう Explorer にくっついてる意味無いと思うんだよね。
ほとんど作業用のウィンドウ開くだけじゃん。
WinCvs のような独立アプリがいいんだけどなあ。

>>251
つBzrExplorer
まだ一般向けベータになったばかりだけどね。

Tortoiseの欠点は、ファイルやディレクトリ一つ一つにオーバーレイをするかどうかを
問い合わせるので、PC全体の動作が遅くなること。
同じシェル拡張でも、「このディレクトリでBzrExplorerを開く」を出すくらいだと
軽くていいのにな。

>PC全体の動作が遅くなること。
どんだけしょぼいマシン使ってるんだよｗ
オーバーレイの設定次第でやたら重くなったような気もするけど
デフォルトで使ってる限り欠点として挙げるほどのものでもないよ。

TortoiseSVNの話だが、最近はそれほど気になる速度低下はないよ。
キャッシュとか色々工夫してるみたい。
少なくともワーキングフォルダ外ではToetoiseの影響は感じない。Explorerのクラッシュも見ないし。

むしろ速度重視のせいか、オーバーレイアイコンがちゃんと更新されてない場合も多いがｗ

>>253
svn みたいに各ディレクトリに .svn ディレクトリがあるとまだマシなんだけど、
hg/bzr/git みたいにルートにしか管理リポジトリが無いと、あるディレクトリ
アイコンのオーバーレイをするには、

1. そのディレクトリ自体がリポジトリじゃないかチェックする
2. そのディレクトリの親やさらにその親に .?? がないか探す
3. 1か2であったら、リポジトリを開く
4. リポジトリの内容を検索し、該当ディレクトリがバージョン管理されているか
確認する。
5. 管理されていたら、そのディレクトリの中の子ディレクトリ、孫ディレクトリを
再帰的にチェックしていき、一つでも変更されているファイルが無いか
確認していく。あればそのディレクトリは変更されているアイコンを、なければ
up to date アイコンを表示する。

って感じで、親方向にも子方向にもトラバースしないといけないんだよ。
SSD じゃないノートPCだとHDDのランダムアクセス遅いから明らかに重くなる。

>>254
svn は .svn が分割されているから速いんだよね。
もちろん、他の Tortoise 系が重いのはまだキャッシュ管理が
適当だったりするのもあるんだけどさ。

そもそもエクスプローラから操作できてもあんまりうれしくはないんだよなあ。
統合環境使うならそっち経由で操作できることの方が重要だし、
キーボードでコーディングしている以上、別にコマンドラインでも苦にならないし。

まあ、実際俺も、不具合多すぎて、コマンドライン版ばかり使ってるわｗ

ちなみに、Unicode対応をうたうbzrは今までコマンドラインオプションを
コードページでデコードしていたのでコードページに対応していないUnicode
文字はコマンドラインから指定できなかった。
1.16 からは、 GetCommandlineW() を使うようになって、cp932で表せない
ファイル名もコマンドラインで扱えるようになった。

hg の場合は fixutf8 拡張を入れると、GetCommandlineW() を使ってくれる。
git の場合はutf-8 cygwin で同じく可能だった。
二次配布とか拡張に依存しないのは素晴らしいけど、もっと早く対応しろよ>bzr

>>259
hg/bzrでのsys.argvの問題はpython側の実装が根本的な原因。GetCommandlineWを直接呼ぶのはハックの一種。
gitは言わずもがなcygwin側の問題。utf-8 cygwinを本家にマージさせようとする奇特な人は皆無。

utf-8 cygwinじゃなくて、cygwin-1.7系だと何かマズいんかな。

>>260
Python 3.0 では、 main(int argc, char** argv) が wmain(int argc, wchar_t** argv) になって、
何もしなくてもUnicode文字列が得られるんだけどね。
まだまだ Python 2.x が主流だから仕方ない。

bazaarでssl client cert file はどこで指定するんだ？

>>263
SSL って?
bzr webdav で https 経由で push するとか？

linux板から

ファイルの先頭部分のコメントあたりで
　/*
　 ....
　 * $ Header:　...　(なんかかいてある) $
　 */

これってバージョン管理ソフトに読ませるための情報だったんですね
どのバージョン管理ソフトも対応してるのかな

>>265
してない。
してるほうが少ないのでは。

>>265
rcs、cvs、svn(標準で無効)、git(標準で無効)、bzr (bzr-keywordsプラグイン・標準で無効)は対応してたはず。hg? 知らね。

hgは拡張で対応
ttp://mercurial.selenic.com/wiki/KeywordExtension

バージョン管理ソフトに読ませるための情報じゃなくて、
バージョン管理ソフトが人間に読ませるための情報じゃないの？

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

よく分からないのですが、IDが対応したリビジョンを一意に特定できれば良いのだから、
後からログを変更したとしても、IDを再計算する必要はないのではないでしょうか。
ログが変更できない理由になっていないと思うのですが、どうなのでしょう。

>>270
IDがハッシュ値だっていう意味はわかってます?

>>271
そうか、ハッシュが衝突するログを掻けばいいのか。

>>270
>IDが対応したリビジョンを一意に特定できれば良いのだから、

原理的にはそうなのですが、分散VCSでは複数のリポジトリが互いに独立して存在するので、
再計算しない場合は、同じIDなのに内容が異なるリビジョンの存在を許してしまいます。
それはまずいので、再計算する必要があります。

これが分散型でないなら、ID発行元が一元管理されているので、再計算の必要はありません。

>>273
なるほど〜。良く分かりました。

となると、ログを後から楽に変更できる分散VCSを作ろうと思ったら、
ハッシュ値の計算にログの情報を含めなければいいんですかね。
でも、ログもリビジョンの重要な要素だと考えるなら、この設計はまずいかもしれませんね。

ありがとうございました。

>>274
>ハッシュ値の計算にログの情報を含めなければいいんですかね。
その設計はありだと思います。
あるいは、コミットとはべつにあとからログを付加できる仕組みを追加するとか。
たとえばどのVCSでもコミットに対してあとからタグを付けられますけど、
これと同じ感覚でログをあとから付けたせるようにし、それがあればそちらを優先して表示するけど
なければコミット時のログを表示する、というのでもいいかもしれません。
なんというか、コミットに対してあとからメタ情報を付加できる仕組みがほしいですよね。
タグはちょっとプリミティブすぎる。

ハッシュ値の計算に親コミットIDを含めずに計算するとかはどうかな。
これだと、データを変更したコミットのIDと、その子コミットの親コミットIDを変更するだけで、
子以下のコミットのIDを再計算しなくても良いはず。

編集していない子以下のコミットのIDを変更してしまうのには多少違和感があるけど、
（同じコミットにもかかわらず、他のリポジトリのコミットとIDが変わってしまう）
これだと回避できるかな。
mergeの処理もこの方が速いかもしれない。
もっとも、後からデータを変更する需要がどれ程あるかは分からないけど。

>>276
分かりにくい表現ですみません。
一応訂正。

> 編集していない子以下のコミットのIDを変更してしまうのには多少違和感があるけど、
編集していない子以下のコミットのIDを再計算して変更してしまうのには多少違和感があるんだけど、

Gitの場合だけど、ログの内容もコンテンツも全て同一でコミットし直しても
ID変わっちゃうんだよね…ID作る時に日時も使ってるからだと思うんだけど。
親が同じでコンテンツの内容も同じなら同じIDでもいいんじゃないかな〜とは思う。
ただログの内容が違う場合はID変わるのはしょうがないかな〜
世界中で同じコミットだとして認識するにも関わらずログの内容がばらばらだと
ちょっとおかしなことになりそう。ログを考えなければ同じモノなんだけどねぇ。

git の仕様を分散VCS一般みたいにされてもな・・・
Bazaar は sha1 じゃなくて uuid を使って、
その代わりにコミットに署名をできるようにしている。

これは……

>>279
>Bazaar は sha1 じゃなくて uuid を使って、

違いを詳しく教えてください。uuidとやらを使うと、コミットの内容とは関係なくコミットIDを発行できるということ？

>>281
コミットの内容と関係ない revid は発行されるが、昔のコミットのコメントを
書き換えるようなコマンドは無いな。

ちなみに、普通は長い revid ではなく短くてブランチローカルの revno を
使って作業する。

>>278
>ID作る時に日時も使ってるからだと思うんだけど。
>親が同じでコンテンツの内容も同じなら同じIDでもいいんじゃないかな〜とは思う。
お前アホだろwww

Bazaarは署名+擬似乱数をIDにしてる訳ね。
それなら、コミットの内容を後から変更したとしても、
GitのようなIDの再計算はいらないな。

>>283
くわしく

>>284
厳密に言うと、id がハッシュじゃないと同じハッシュのリビジョンを偽装できるから、
誰かがこっそり変なコードを紛れ込ませる事が可能になってしまう。
だから id と別に署名が付けられるようになっているだけで、署名は付けなくても良いし、
署名は id の一部じゃない。

>>286
署名の必要性がいまいち理解できないわ。
そんなに神経質になる必要あるのかな。

例えばsvnに偽装防止の仕組みってあったっけ？

>>287
> 例えばsvnに偽装防止の仕組みってあったっけ？
svnはsshなりhttpsなりで認証しているのが前提だからな

>>287
例えば、 bzr send -o バンドルファイル みたいにすると、バンドルっていう
パッチセット+リビジョン情報みたいなファイルができる。んで、それを
メールで送ったり、掲示板に貼り付けたりするから、man-in-middle に
改ざんされる恐れがある。

まぁ、神経質な人が使えば良い機能。俺は使ってない。

おまえら、悲惨な目にあったんですが、助けてください。

Mercurialで元ファイルがCRLFの改行コードのテキストファイルを突っ込んでいたのですが、
ある日一部ファイルが壊れたので、元に戻そうと hg revert hogeしたわけですよ。

そうしたら、LFの改行コードで元にもどったわけですよ。
途中まで、気づかずにリポジトリ管理下に入れてたアプリがおかしな挙動して、すげー時間くったわけですよ。
LFになったくらいなら、CRLFに変換すればいいんですが、
毎回、取り出した際に、LFになっとるってこんなことあるんですかい？

これって、どうやったら、CRLFそのままで管理してくれるんでしょうか？
もしかして、リポジトリ作り直し…？(; ´д｀)

環境：Windows Vista SP2, Mercurial 1.2.1 (TortoiseHg0.7.5付属のもの)

ごめん、一発で解決したｗ

Mercurial.iniに以下のように hgext.win32text とその諸設定を書き忘れてた(´･ω･`)

[extensions]
hgext.win32text=

[encode]
** = cleverencode:

[decode]
** = cleverdecode:

hgext.win32mbcs外す時に一緒にコメントアウトしていたらしい・・・

しかし、hgext.win32text組み込んだ時って、コミットしたファイルがLFでリポジトリに突っ込まれているのか…。
以前にコミットしたのは、全部hgext.win32text組み込んでたんで、LFになってるみたいだ。

この勝手に変換するのって、もしかして、場合によってはヤバくないですか？
例えば、cygwinのshって、LFでないとエラーはくんですが、リポジトリから吐いてCRLFになってるとマズイじゃん？

>>291
そもそもwin32textに頼らなきゃいいんじゃね?
改行コード混在の環境は想定されてないんだし。

>この勝手に変換するのって、もしかして、場合によってはヤバくないですか？

この手の変換って悩ましいけど
まぁよくあることなので
慣れちゃうんじゃないかなー

>>292
> 改行コード混在の環境は想定されてないんだし。

だよねーだよねー

そうか、win32textを始めからつかわなきゃいいのか。
でも、そうすると過去にwin32textで入れた奴だけwin32text使うわけか。
イチイチきりかえ面倒クセー！！
悩ましいなｗ

>>294
1. win32text を外す
2. checkoutし直す
3. LFになってるファイルを全部CRLFに書き換える
4. commit

>>295
やっぱりそれしかないか…

>>291
> この勝手に変換するのって、もしかして、場合によってはヤバくないですか？

今ごろこんなこと言う奴がいるとは驚いたな。
テキストの場合、行単位での管理として特定の改行コード(たいていは LF)でリポジトリは統一、
チェックアウトの際に、それぞれのプラットホームに合わせて改行コードを変更。
至極当然な動作だと思うがね。

少しお聞きいたします。

git で 普段 pull, push するのは リモートA で、
ある時だけ、リモートB から pull を指定したいということはどのようにしたら可能でしょうか？
リモートAは自由に出し入れ(マージというか)するのですが、
リモートBにはpushしたくないので、指定した時のみ片方向にpullしたいという感じです。

>>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

288ではないですけど>>299をみて思い出したので質問します。
git で origin/master と指定するときと origin master と指定するときの２種類が
あるみたいですけど、この違いってなんでしょうか。
どういうふうに使い分けるかよくわかりません。

>>300
origin/master は リモート"origin"の"master"ブランチの指定で、
origin master は<repository>と<refspec>がスペースで区切られて並んでいる状態。
git pull <options> <repository> <refspec>…

>>301
ですから、その違いは何かということなんですけど。
たとえば git pull origin master は OK で git pull origin/master は NG とか
そういう違いがあったとして、なぜ git pull origin/master は NG となるのか。
origin/master を指定できるところには origin master は指定できるのかできないのか、
逆に origin master を指定するところに origin/master と指定していいのかどうか。
できないとしたら、それはなぜか。両者にどう違いがあるのか。

>>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/

>>299
改行を統一しないと差分が正しく取れないから変換するしかない。

そもそも win32text という改行を変換するextentionを入れておいて
勝手に変換するというのは難癖だろ

>>304
取れないってことはないでしょ。
改行混合でもちゃんとうまくやって
ほしいなあ。

たぶんsvnはできてるんだよね？

>>306
LFの文書が入ってるところにCRLFの文書がコミットされたら、差分をどういう状態で格納すればいいのかと。

svnも、リポジトリに入れるのは全部LFだよ。入れるときと取り出すときにクライアント側に合わせて自動変換。
最初からWindowsや旧Macの事も考えられてるから、使う側は意識しなくてもうまくやってくれてる。

svnはそんな変換しなくね？

え？

subversion は svn:eol-style で改行の振舞いを決める
default はそのまま
勝手に変えることは無いよ

ttp://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5
デフォルト(=無変換), native (=クライアントに合わせる), CRLF, LF, CR、の5種類だね。

>>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 と指定しなきゃいけないのは、
わかりにくくてしょうがいないです。

>>312
乱暴な言い方かもしれないが、思想の違いなんだろうな
同じような機能(元々同じ目的だから)を有するmercurialともリポジトリの
考えが違う
gitのブランチは各々違うレポジトリを差すことができる

>>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と指定するときってどんな時があったけ？

>>306,310
ごめん。すっかりeol-style=nativeに慣れきってしまっていた。
無変換だと改行コード混在したらまともにdiffは取れなくなるという話が>>311に載っている。

>>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。
ごく自然な書き方だと思うんだけど。。。

つかチュートリアル読んだ？

>>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したほうがすっきりするかも知れない。

>>316
まるっきり外れた回答ありがとうございます。
できればもういちどもとの質問を読んでみてください。
「origin/master」の意味を聞いているわけじゃないです。

>>317
>なんでそうなのかというと、pullはfetchとmergeの合わせ技だから。
なるほど、fetchはリポジトリ名を、mergeはブランチ名を引数にとるから、
pullも引数が別々にわかれているわけですね。
これはわかりやすい説明でした。ありがとうございます。
ただ初心者の観点からいうと、「git pull origin/master」と指定できるようにしたほうが
統一感があってわかりやすいかなと思いました。
（技術的には何の問題もないですし。）

>>318
git pull origin masterと、git pull origin/masterでは意味が違うことにも気づけないの?

>>318
単に使い方を教えて欲しいのか、なぜコマンドがそうなってるのかの理由を
質問してるのか、はっきりしないからなんじゃないかと思うが。
初心者アピールする前に少しはドキュメント読んだほうがいいんじゃない？

なんか難しそうだからgitは触れない方がよさそうだな

Subversionで充分です

RCSで十分とかCVSで十分とかいちいち宣言しなくてもいいような

実際、hg, bzrとgit, darcsは、難度のレベルが違う。
後者は永久に一般受けしないと思う。

>>323
ドキュメントまともに読めないやつはSubversionで十分だと言いたいんじゃ

317のおかげで収まったのに。

>>319
落ち着こう。その2つの書き方は分かりにくいから、後者に統一したほうがいいよねという話。
もうちょっと読解力を持とうよ。

>>320
使い方の質問なんてしてないよ。
あえていえば origin master と origin/master の使い分けについての質問。
もうちょっと読解力を持とうよ。

全部他人のせいなんですよね


( ´Д`) <はぁー ・・・

ドキュメントの読解もできない間抜けが何を言っているのやら。
パラメータを二つ指定するのと、一つ指定するのでは意味が違うってなんで判らないの?
折角の>317の解説さえ理解できていないじゃないか。

>>326はやっぱり理解してねえなｗ
＞あえていえば origin master と origin/master の使い分けについての質問。
使い分けとかいうレベルじゃないからｗ 別ものｗ
スペースで区切ったら別のパラメータなんですよ〜たまたま並んでるだけｗ

>>328,329
そんなに理解するのが難しいこと言っている？
引数を2つ指定している場合でも、gitが引数の解釈をちょっと頑張ればひとつにできて、
かつ他のコマンドと同じ書き方ができると言っているだけなんだけど。

>パラメータを二つ指定するのと、一つ指定するのでは意味が違うってなんで判らないの?
だから、パタメータがひとつでも、指定の仕方で２通りに解釈させることができるってことが分からない？
git checkout なんか引数にファイル名やブランチ名を指定できるでしょ？パラメータをひとつだけ指定した場合でも、
git コマンドが適切に解釈して別々の動作をしてくれるよね。
git の他のコマンドはそのくらい柔軟にコマンド引数を解釈してくれるんだから、git pull も origin と origin/master の区別ぐらいつけたらいいのにという話。

>スペースで区切ったら別のパラメータなんですよ〜たまたま並んでるだけｗ
だから、引数の解釈をもう少し頑張れば別々のパラメータにしなくても済むよねという話なんだけど。
＃これふざけて言ってるのかな。それともマジで読解力がないの？ゆとりすげーな。

こんな所で自分の妄想話を披露してる暇があるんなら自分で作れよアホ

>>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 書いて送ればいいんじゃないの?

>>330
これお前だろ。いつのまにGitのUIを俺好みにしろって話になったんだ？
300 ：デフォルトの名無しさん：2009/06/29(月) 11:34:54
288ではないですけど>>299をみて思い出したので質問します。
git で origin/master と指定するときと origin master と指定するときの２種類が
あるみたいですけど、この違いってなんでしょうか。
どういうふうに使い分けるかよくわかりません。

>>330
だからさ、ちゅーとりある読んだー？
ドキュメント読まずに私初心者ですけど使いにくいですもっとこうだったら
いいと思うって、どんな？
git pullの書式はこう書けたらもっと良いと思うんだけどどうかな？　って
始めから書いてたら、
スルーしてたと思うけど。だってそうは思わないからね。

何か伸びてると思ったら...

>>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のパッチに期待。

そんなことよりそろそろ出るMercurial 1.3が楽しみだ

>>330
> >>328,329
> そんなに理解するのが難しいこと言っている？

内容は一切読んでないので難しいかどうかはわからんが、説明のやりかたがﾄﾞ下手。
まず、読む気にならない。

hg commit .　が
abort; xxx/yyy/zzz: file not tracked!
となるんだが、仕様変更なの?

hg 1.3 出たね。

>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にも有るの？

bazaar の1.16.1も出てるよ！

>>342
おそっ

hg cloneすら失敗するとかどうなってるの？！＞hg1.3

……と思ったらwin32mbcsが有効になってるせいだった
切ったら普通にいけた……

Marcurial 1.3登場、リポジトリをまとめる"サブリポジトリ"
ttp://journal.mycom.co.jp/news/2009/07/03/047/index.html

おーっ、わざわざシェルスクリプト書いてやってたのが
本体機能として実装されそうなんだな。

>>346
今までもforest extensionでほぼ同じ事が出来てただろ

>>347
知らなんだぜよ…。orz
Extension は全然チェックしてなかった。

でも木になってないとダメなのか。微妙だな。
サブリポジトリはどうなんだろう。やっぱり木でないとダメなのかな。
それはそれであるといいんだけど、違ってたらやっぱりスクリプトも必要だな。

Virtual SVN（ver1.71）について質問です。

リポジトリを削除したいのですが、できません。
VirstualSVN Managerでリポジトリを開いて右クリックすると、リポジトリの持ってるファイルは削除できるようなのですが
（ちなみに、Managerから消えてるだけで、DBファイルの実体は残っているようです）、
リポジトリそのものを選択して右クリックメニューから削除しても、10秒くらい反応が返ってこなくなるだけで、
結局消えてくれません。

リポジトリのディレクトリをそのまま消しちゃっても良いのでしょうか？

日本語ファイル名を扱えるWindows GUI環境という条件で、
git,mercurial,bazaarのツール群を試してみたが、現時点では
QGit2.3 + UTF-8 cygwin(又は cygwin 1.7)git が一番マシかな。
というかこれ以外はまだ実運用できるレベルじゃない。
確認してないツールもあるかもしれないから、これは使えるという
ものがあったら教えて。

>>350
bzr 1.16.1 + qbzr の trunk + bzr-explorer

>>351
bzrexplorerはbranchのlocal pathに日本語が含まれると不具合があった
新たなbranchを作る時等
trunkでは直ってるのかな？

hg forgetなんてのが追加されてるのにnewsにはかいてないな。
しかも日本語ヘルプでhg addをみたらhg revertを見ろとなってるし。
gettextでこの辺の管理ってできないんだっけ?
間違ったヘルプを出すくらいなら英語のをそのまま表示してくれよ。

>353
日本語ヘルプで思い出して、Windows版hg 1.3を入れてみたが、
これ、WindowsなのにLANG環境変数の設定が必要なんだな。

しかも、訳が付いてるコマンドって半分もないような。

>>350
あと、2,3年後にきたら少しはよくなったいると思うよ

hg の ML でも bzr が楽しみとかの話題になってるし、依然として開発チームは
Unicode に理解を示さないようだし、hg ダメかな。
bzr 試してみるかな。もう検証疲れたよ…。

Python 3系になればきっと

>>356
開発者の中には、無駄なプライドを背負いこんでるやつらが時々いるんだよな〜。
hgのUnicodeも「やらないって言ったらやらない」って感じだと思うな。

まあ英語圏では本来 Unicode は必要なものじゃないから、
気持ちはわからないでもないんだけど、全世界で使われるものである以上、ねえ。
bzr は配慮してくれてるわけだし。
はー、bzr 用の仮想マシン用意するか。データはどうするかな…。

>>359
＞全世界で使われるものである以上
それはいいがかり。
向こうには使わせる義理も、こっちには
使う義理もないのだから。

もうとっとと見切りをつけるべきでは。
かわりにbzrとかあるんだし。

>>357
Python-dev で、Unicodeにデコードできないファイル名どーするよ？という話題に
なったときに、hgの開発者が「文字列（=Unicode）ではなくバイト列でのファイルシステム
へのアクセスは必要だから、例外的な回りくどい方法にしないでくれ」みたいな
事を言ってた。
mercurialはPython3kになってもきっとファイル名はバイト列のまま。

githubでもbzrが使えればbzr使うんだが

githubよりlaunchpadの高機能な気がするが、どうしてもgithubでbzrを使いたいならbzr-git使えば良くね?

>>363
bzr-git は、pull と gitプロトコルでのserveしか対応してないからムリポ。
stacked branch とか bzr の良いところを利用するにはやっぱり launchpad。
wikiが無いのは…

素直にgit使った方がいいんじゃない？
使ってりゃ慣れるよ。
余計なことしないからUTF-8環境なら逆に問題は少ないし。

> 使ってりゃ慣れるよ。
いまひとつ信じ難い
コマンドの名前はともかくとして、本当にあのオプション設計に慣れるのか？

>>361
WindowsとUnix系の違いってのは理解してもらえないもんなのかねぇ。

今の世の中、Windows は避けて通れないのに、
なぜかおざなりにされるんだよね。

>>368
逆に考えるんだ

憎まれっ子世に憚ると申しまして。

>>366
道具に人間の手の方を合わせるのはバカげているという考えには同意する。
ただ質問の答えなら YES だ。
(それにgitがそれほどバカげた道具だとも思わない。名前以外は。)

>>367-368
Windows対応もマルチバイトファイル名も開発者が(コミッタ？)その環境で使ってないから、につきる。
何が酔狂に好き好んで、自分の使ってないマシンとか環境の面倒も見なけりゃ意見のだ？
金貰ってやってるような仕事じゃないんだぜ？

よくあるだろ、Windowsのフリーソフトのフォーラム覗いたら、
「Mac版も作ってください」「知るかボケ(やんわりと)」って受け答え

俺はWindowsを非難しているわけじゃないぞ。おれ自身はむしろ、Windowsもクライアントで、Linuxも鯖で使ってる方だからな。

別にcp932だけが悪い訳じゃなくて、UTF-8でも正規化の問題とか、Mac OS Xで
あったりするじゃん。
svnを置き換えるような、クロスプラットフォームで汎用のバージョン管理ソフトには、
やっぱり環境依存なファイル名の扱いを吸収してくれる機能が必要なんだよな。

Linuxだけでファイル名のエンコーディングも全nodeでそろえられるような限定された
環境か、Windowsにはcygwin入っているのが当たり前っていう人のコミュニティの中で
しかgitはムリだと思う。

>>372
rubyのmatzがそれでMacもらったりしてたよな
実際にMacの対応が良くなったかどうかは知らんが

やったことないけどGitでCP932にそろえればいいんじゃね？
UTF-8はうまくいってる気がする。

>>376
UNIX側でCP932をデフォルトエンコーディングにすると確実に死ねると思うのだが。
何処に行ってもUTF-8にするのが無難な解。
# とは言え、そっちはそっちでNFC vs NFDとかWAVE DASH問題とか……orz

Unix（というかPOSIX）ではファイル名は単なるバイナリ列なんだよね
'\0' と '/' が特別扱いされるだけで

この意味では hg/git のやり方にも一理ある

>>377
＞UNIX側でCP932をデフォルトエンコーディングにすると確実に死ねると思うのだが。
滅多にやらないけど、ロケールSJISってなんか問題あるっけ？

＞何処に行ってもUTF-8にするのが無難な解。
そりゃそうなんだけど、Windowsの人が日本語ファイル名ダメだって言うから。

>>378
＞Unix（というかPOSIX）ではファイル名は単なるバイナリ列
それはファイルシステムの話だろ。
シェルやアプリケーションがどのように
扱うかはまた別の話。

>>379
2バイト目が0x5c
>>380
posix api の話
>>378
gitにとってはWindowsは公式サポート外だから別に良いけど、
hgはWindowsも公式サポートされている。

NEWSはShift-JISがデフォだったけどな

昔のHP-UXもShift-JIS。 今は知らない。

またcygwinはwindowsじゃないというトンデモか

>>378
Unix系は問題ないんだよ。　
Windowsでは文字列として扱ってもらわないと困るって話。

Cygwinは、UTF-8 Cygwinが標準になってくれれば…。

Windowsも使わないし日本語ファイル名も使わないわしにとっては別にどうでもいいなと思った

>>361
デフォルトはそれでもいいから、extensionとかで簡単にbzr的な扱いにもかえ
られるとうれしいんだけどな

>>385
Cygwin-1.7入れてLANG=ja_JP.UTF-8を設定すればおk。
日本語ファイルだらけのワーキングコピーでsvn updateしても無問題。
6月正式リリース予定だったのに、まだMLでproblemだのissueだのPATCHだののSubjectなメールが飛び交ってるが……。

>>379
全てのコマンドがそれに対応していれば問題ない。>>382-383はそういう環境だな。
しかし、コマンドラインやファイル名を単なるバイト列と思ってるコマンドが1つでもあると、そのコマンドを使った時点で破綻する可能性が出てくる。

ここは間をとって、バイト列とエンコーディングのペアで保存すればいいんじゃね？

ruby の文字列がそんな感じだったような。

>>390
改行で1バイト削るためにLFにしちゃうような人種がそんな無駄をするはずがない気が・・・

>>391
改行を LF にするのは当然で、２バイト以上使うのがただの無駄だろ。
それに日本語について考えれば、 UTF-8 で統一するのに比べて Shift_JIS や EUC-JP を
使ったほうが、容量的にはむしろ節約になる。

エンコーディングとペアで保存する場合の問題は、デコード時の処理負荷のほうでしょ。

リポジトリに何でも入れられるようにして出力側で変換するよりも、
リポジトリに突っ込むときに正規化したほうが、いろいろな環境間で
データをやりとりするプログラムにとっては正しいデザイン。

現にUTF-8 で統一してるSubversionにケチ付けてる環境の人って居るの？

>>393
じゃ、おまえはこれから英語しかしゃべるな

>>393
正しいなんて言うのはどうかしてる。
そんな機能は後回しになるのが普通だろ。

>>394 OSXとWindowsで、濁点がついている文字が入っていたりするとうまく動作しない。(NFD問題)

>>397
ファイルシステムで吸収すべき問題なのか、
アプリでがんばるべきか、前者な気はする。

>>397
それも、バージョン管理システムがどうにかするべき問題だよな。
リポジトリに入れるときにはどれかの正規化をしておいて、取り出すときに
その環境の慣習に沿った形式に切り替えればいい。

>>397-399
こういうのがある
http://d.hatena.ne.jp/fujisan3776/20081231/1230700127
本家には取り込まれてないみたいだけど

>>386
まあ、作ってる側もこういう感じなんだろうな。

>>401 >>386
まさにそのとおりだな・・・

直すにはマルチバイト件のやつらが、でかい声を上げて手を上げていかなきゃならない。

Subversionのときは、どうだったけ？TortoiseSVNがちゃんと日本語扱えるようになるまで、
けっこう時間かかった覚えがあったけど。大体2,3年くらい科方と簿絵がある

しかしパッチも受け付けない姿勢には共感しかねる。

パッチを受け入れるのって面倒だぞ。
対応だけで手一杯になる。

だからGitにしろと(ﾏﾃ

今更ファイル名の取り扱いを変更したら互換性が崩壊するから十中八九無理だろうよ

cygwin上のgitも速くなったから実際のところ悪く無い。
GUIがgit.exeを呼び出す形で分離されてるから locale の問題ではむしろ
良い方に働いてる。

TortoiseHg 0.8 だが、win32mbcsを設定したとたん
コミット等まともに動かなくなるようなのだが。
以前はそんなこと無かったのに。

>>408
誰かが壊したっぽい。

win32mbcsを作ったひとが直してくれてるから、次のリリースでは大丈夫だろう
ttp://groups.google.com/group/mercurial-ja/browse_thread/thread/59c4fe5b7409e509

マルチバイトファイル名公式非サポート、
これでWindowsで普及させようなんてアホすぎる・・・

win32mbcsは公式コンテンツですよ

サポートが弱いのはその通りだと思うけど
だからって妄想はほどほどに

>>412
公式？ｗ

Vista SP2 上で cygwin の最新 git 1.6.1.2 を使っています。

.gitconfig に git status を git st で alias 登録しました。

プロジェクトの toplevel では git st で正常に動くのですが、
下の階層のディレクトリに降りて git st すると
全ファイルが modified: とだーっと表示されます。

なので今は git status を書いたバッチファイルを使っているのですが、
解決策をご存知の方はいませんか？

>>414
gitスレでやれ

>>415
Gitスレでこっち誘導されてる。
あっちはLinux板だからCygwinならこっちのほうが知ってる人いるかもね。

>>415-416
すみません。。。そして、ありがとうございます。
同じ状態の人はいないのでしょうか。

>>414
再現しない
環境：Vista SP2, cygwin (UTF-8DLL) , git version 1.6.1.2

最低限再現するgitリポジトリを用意して、githubにでもうｐれ

質問なんですが mercurial で commit 時にある特定のファイルにその commit 時の
hash 値を自動で埋め込むってことをしたいのですができますかね。

[extensions]
hgext.keyword =
[keyword]
* =

とかして、
$Revision$ を埋め込んでるんですけど、どうやらそのファイルが
更新されたときしかリビジョン番号の更新をしてくれないみたいで
困ってます。

>>419
自分の体重を計るときにその計測結果の1/10の重さのおもりを持って
計測できるか？

>>420
わかりにくいたとえ。

>>419
後処理でそれをやってくれるスクリプトを書かないとムリじゃね？

>>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

>>423
どうもありがとう！！
まだ試してないですけど、フック使うって手法で
がんばってみます。

>>421 うん、ごめん。 >>423-424 見て反省してる。

>>423-424
ムリ。ハッシュ値ってのは、コミットする内容を元に計算しているから、
ハッシュ値をコミットする内容に含めるとハッシュ値が変わってしまう。

pretxncommit は、コミットする内容が確定してリビジョンまで決まった後の
コマンドだから、その段階でファイルを弄ってもコミットには反映されない。

たぶん、ハッシュ値を使って何を実現したいかを説明した方がいい気がする。
バイナリかリリースするソースにハッシュ値を埋め込んでおきたいのかな、
という気はするけど。

>>419
ファイルが更新されないとリビジョンも更新されないんだから当たり前だろwww

>>427
CVSやSVNならそうなんだけどね。
ttp://hgbook.red-bean.com/read/behind-the-scenes.html
hgリビジョン番号ってfigure4.2でいうところのchangelogのrevidじゃないのかなぁ。

hg tagしたら自動生成されたコミットログが日本語になっとる。

>>428
それはリポジトリのリビジョンでファイルのリビジョンじゃねーだろwww

>>430
それはそうだが、
hgではファイルのリビジョンを知る方法はないよ。
hg debugindexをつかえば、一応見られるが。

>>431
logで見れるだろwww
debugindexってまだあるの？

hg tip ファイル名
で見れない？

すいません、
hg parent ファイル名
でした。

>>434
出てくるのは00changelog.iのリビジョン番号だし、
ちゃんとchangeset:って書いてあるし。

>>435
すまん、問題を取り違えてたわ。

今まで一つのリポジトリを研究室と自宅で操作してて、
コミットし忘れが結構な頻度で発生して面倒だったんだけど、
OSの起動時にフックして自動的にpull/pushしてくれるようなソフトない？
使ってるVCSはbazaarだけど、これがあるならgitだろうがmercurialだろうが移行するぜ。

なかったら言い出しっぺの法則で暇を見て作ろうと思います。
ちなみに皆さんはどうやって同様の問題を解決してますか？

>>437
リモートログインしてpushすればいいんじゃね?

＞OSの起動時にフックして自動的にpull/pushしてくれるようなソフトない？
Windowsでしょ？バッチファイルをスタートアップに入れておけばいいんじゃね？

>>438
出先のPCは電源を落としてるので、リモートログインはできないのです。
もっとも研究室のPCなので外からログインできるかは微妙ですが
（VPN使う手もありますが、なにかとまずそうなので・・・）

>>439
主にubuntu使ってますが、windowsも開発で使わなければならないときもあるんで、まあ両方ですね。
linuxでもdaemonとかいう、いわばサービスにファイルを登録するだけで起動/終了時にスクリプトを走らせることができます。
ただ、それだけでは終了時のpushができなかったり、スタンバイやハイバーネート、スリープなどに対応できないと思いますので、
結局フックやらを考えないといけないとは思いますが・・・


現在考えてるソフトウェアの構成はこんな感じです。

・VCSをpull/pushするスクリプト（おそらくRubyかPython)
・OSに上のスクリプトを走らせるためのソフトウェア(Windowsならサービス、Linuxならdaemon?)

最初はbazaarとlinuxで試してみて、それが出来次第他のVCSやWindowsもできたらいいなと思っています。

.bash_profileと.bash_logoutじゃいけない理由でもあるの?
まぁ、logoutする習慣がないなら泣け。

# しかし、本質的にはその辺りは自動にするより習慣付けるのが一番ではある。

自宅のPCにリモートで入ればいいじゃん

>>441
まあその辺の手も考えなくはなかったのですが、
普段もっぱらscreenを使用してるので.bash_logoutスクリプトが自動的に呼ばれないことと、
複数のリポジトリを更新してほしいときなどに面倒なので、それならいっそリポジトリのパスを含めた設定ファイルと、
それをpull/pushする簡単なスクリプトを書こうと思ったわけです。

> # しかし、本質的にはその辺りは自動にするより習慣付けるのが一番ではある。
まあおっしゃる通りなんですが、分散型を使ってるとcommitはともかくpushは忘れがちで・・・。

馬鹿じゃない?

>>443
screen使用とログアウトしないこととの関連が判らんが、
「複数のリポジトリを更新して欲しいとき」という要求が発生するタイミングがあるなら
まさしくその瞬間に自分でpushするスクリプトを起動すればよいのでは?
pushを忘れるのが嫌なら、例えばコンパイル時にpushするようにMakefileを書けばいいだけだし、
やっぱり何をしたいのか判らない。

cronで定期的にhg outgoingみたいなので未pushの一覧を出力してメールで飛ばせ。

>>443
pushを忘れがちというのには同意。
pushされた側でupdateをわすれがちなのもあるよね。

>>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してくれればいちいち気にせず使えて便利だと思ったわけです。

>>448
すいません、一部言葉足らずな部分があったので修正させてください。

> >>446
> なるほど、それならメールをチェックしていればどれをpushしていないのか分かりますね。
> でも、例えば長時間起動してcommitしながらOS終了時にpullするような使い方だと、
> チェック時に毎回メールするようだとメールがどんどん増えていってやがて見なくなるでしょうし、
> 一回だけだと逆に終了時に忘れてしまうような気がします。

でも、例えば長時間"PCを"起動してcommitしながらOS終了時にpullするような使い方だと、
"cronの"チェック時に毎回メールするようだとメールがどんどん増えていってやがて見なくなるでしょうし、
"差異を発見した一回目"だけだと逆に終了時に忘れてしまうような気がします。

>>449
cronでpushしちゃえよ。人間になれない人にはぴったりだ。

DropBox使えば？

>>450
＞人間になれない人
???

>>451
まさにそのDropBox的な使い方をしたいのですが、
DropBoxだと容量に制限があったり、履歴管理に柔軟性がなかったりするので、
できればVCSを使って同様の機能を実現したいのです。

間抜けってことか。

>>437
bzr なら branch じゃなくて checkout したら良いじゃん。

分散型使うのやめればいい

そもそも437の使い方で、push忘れは大きな問題になるのか？
逐一pushしなくても問題がないのなら、思い出した時にだけpushすればいいと思うんだが

USBメモリにリポジトリをおけば解決?

>>458
大丈夫、>437ならそれでも忘れてくれる。

私はそうしているけどね。

>>455
>>456
その手は全然考えてませんでした。
ですが、集中型を使ってもやっぱりcommitを忘れると同様のことが起きそうですね。

>>457
研究室で編集したものをpushし忘れると、
自宅に帰って続きをしようとしたときにせっかく変更したファイルを得られなくなるんです。
実際にはそういったことが何度もあったわけではないのですが、
分かりきった作業に毎回毎回気を配るのは面倒だと思った次第で、それなら自動化できないかと思いました。

>>458
すいません、ローカルリポジトリ/中央リポジトリどっちをUSBメモリに置いたときの話でしょうか？

>>460
さすがにcommitを忘れるようなら、集中だろうと分散だろうと自動pushしようとどうにもならんよ
まさか任意のタイミング（シャットダウン時）で自動commitするわけにもいかんだろう

たしかに commit 忘れも救うってのはダメだな。
何のための commit なのかわからなくなる。

必要なのは VCS+α じゃなくて自動ファイル同期機構だろう。

>>460
自宅で作業するときに pull すりゃいいんじゃねーの？
push に気を使うよりか作業前に pull する方が習慣として
楽なんじゃないかと思うんだが。

>>463
そもそもpushされてないのに、どうやってpullしろと。

スケジュールかtodoでpushアラート出して、自分を誘導して実行していくのが確実な気がする。
アラート無視はもうやる気がないとしか。

素直に集中型のVCS使ったほうがいいんじゃね？

ってか、gfsとかcLVMとかを使って作業コピーや分散リポジトリのあるディレクトリを
丸ごとどこか外に追い出せば済む話みたいに聞こえるんだが。
SCMとか以前の問題だろ。

コーディング用のノートパソコンを一台用意する
commit忘れちゃう437を救うにはこれしかない

いっそのことコード書くのも忘れちゃうというのはどうか

>>460
VisualStudioとかの統合環境にプラグイン入れれば、閉じるときに更新されてれば
commitするか聞いてくれるよ。

>>460
研究室と自宅で同じ作業するなら中央もローカルも USB 上でやればいいだろ

>>465
問題はコミットし忘れなんだから、集中型だろうがだめだろ

>>469
437なら閉じずにハイバネートするだろうな

SCMを使わずにNFS/Sambaで同じディレクトリを共有。
開発もその上でやれば、保存した瞬間に同期される。

>>473
437ならファイルを保存し忘れる可能性もある

437なら自分が何者で、どこに帰って良いのか忘れてしまう可能性もある

Launchpad is now fully open source
http://beuno.com.ar/archives/144

437のことはもう許してやれよｗ

許してやるから出てこいよ

Mercurialのextdiffでフルパス送る方法ないですか？

>>479
extdiffはテンポラリにcdしてからファイル名のみを渡します。
pwdを拾うラッパーを書けばよいのではないでしょうか。

>>480
ありがとうございます。やっぱそれしかないんですね。
もうPython勉強して自分でパッチ書いた方がいいかな……。

/home 以下を全部差分バックアップするのにお勧めなのはどれになるのでしょうか
そういう使い方するものではないのでしょうか？

>>482
あくまで俺の感想だけど、SCMはバックアップ用途には使いにくいと思う。
リポジトリも増える一方だし。

個人的にはバックアップではrdiff-backupを使ってる。
rsyncに履歴をつけたようなやつ。

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

おっ、ついにきたのね。さっそく試してみるか。

なんでウブンツでしかビルドできねーんだ

これまでCanonicalが使って来た分に関してはそれで十分なわけで。

Mercurial 1.3.1出たね
win32mbcsがこけてたのが直ってる

なにィ、昨日サーバー設定してて、1.3 入れたばかりなのに。
まあ蓄積用のサーバーだから細かいことはいいんだけど。

AGPL に注意

>>489
わかちこ、わかちこ

昨日1.3落としたけど
バージョン上げるのﾏﾝﾄﾞｸｾ('A｀)で放置した俺は勝ち組ｗ

TortoiseHg0.8.0入れたらcommitのUIとか立ち上がらない…。
みんな使えてるの？

>>493
亀hg0.8はhg1.3内蔵で、
hg1.3はwin32mbcsが壊れてるのでそうなる。
有効にしてない？

TortoiseHg 0.8.1(with Mercurial 1.3.1)
ってもうできてるんじゃん。
ttp://bitbucket.org/tortoisehg/stable/downloads/

hgsccも新しいの出てた。
てっきり最初のバージョンだけで放置してると思っていたが
5月にも更新されてたんだな。

>>494
有効になってた。
ありがとう！

hg0.8.1だと、win32mbcsでエラーはないが、ダメ文字はコミットできないみたいね…。

Mercurial、エディタの制御まともにできないの直ってる？
コミットメッセージ再編集不可なのはどうせ直ってないんだろうなあ
まともな分散型が使えるようになるまであと何十年かかるかな

レポートされなかったバグはないのと同じ

no

ちょっと試すぐらいの気概もないならやめちゃえば。

darcsで日本語ファイル名は使えますか？

単発の設定ファイルなんかをいちいちリポジトリを作らずに
スナップショットとるようなツールってないのかな。
ボリュームシャドーコピーやTortoiseSVNのような使い勝手で
スナップショットとるタイミングはユーザーが明示できるようなもの。

ちょっとしたINIファイルなんかを念のためバージョン管理下に置いておきたいんだけど
かといって従来型のはちょっと面倒と言う時に気軽に使いたい。

設定ファイルをシンボリックリンクで一箇所に集める。

hg, bzr,git
ソースを読みやすいのはどれ？

>>503
UNIX ならそういう用途だと自分はいまだに RCS 使っちゃうなあ。
/etc の下のファイルいじるときに、あまり自信のないときには ci してから編集したり。

>>506
俺もRCS使う。
同じ用途でMercurialも使うけど、RCSほどインストールされてない。

git 使うようになった

etckeeper使うときのメリットってある？

リポジトリをUSBフラッシュメモリに入れられて、
それをWindowsからでもLinuxからでも使えるような
バージョン管理システムってあるでしょうか？

機能だけならDropboxでも十分なのですが、ネットワークが
ないところでも使えてデータはローカルに置いておきたいです。

svn

>>510
分散型なら普通にできるんじゃない？

>>511
Subversionはリポジトリ内のロックファイルやフックスクリプトの改行コードが
OSに依存しているみたいだから、そのまま使えないかも。

他のプログラムが頻繁によばれるような使い方するなら
cで書かれたgitが一番速度も速いし安心なのか

svnのリポジトリってOSに依存してるのかと思ってましたけどFSFSなら
大丈夫そうですね。USBメモリ上のリポジトリでWindowsとLinuxの両方から
co, ciしてみましたがちゃんと動いているようです。

しばらくバックアップ取りながらこれで使ってみます。
ちなみにUSBメモリはFAT32、WindowsではCygwinを使っています。

>>512
全然詳しくないですけど、分散型でもリポジトリのデータは
OSに依存してるものとかあるんじゃないですかね？

>>513
今回はロックもフックも使わないので大丈夫そうです。
ただ、どこかで問題が起きるのではと心配しています…。

リポジトリがOS依存ってｗ
そんなの使い物にならなくないか？

ていうかあるの？
Bzr, git, hg, SVNを平行して使ってるんだけど、こええな

分散型だからといってOS非依存が条件なわけでもないだろ
クライアントやプロトコルがOS依存って話でもないのに何を怖がってるんだ？

>>515
SubversionでもBazzarでもUSBにリポジトリを置いているけど問題ないよ。

>>517
USBの中に入ってるレポジトリがOS依存だったら大問題だろ

補足
USBメモリの中に入ってるレポジトリが、たとえばWindowsに依存していたら
LinuxからそのUSBメモリを開いたとき、レポジトリの中身が見られなくなる、という意味ね

改行コードとかは属性付けておけば良いだけだし
フックスクリプトなんてWin用とLinux用でも作っておけば良いじゃん

>>519
アホ？

>>519
リトルインディアン嘘つかない

>>520
そのことと>>517に何の関係があるんだ？

分散型であることとリポジトリ自体が異なるOS間で可搬であることは何の関係も無いよね。
リポジトリ自体の物理的な保存場所をOSまたいで持ち運ぶような用途が想定されているかどうかだけ。
物理的な格納の仕方の話だからファイルシステムも関係ある。
分散は関係ない。

なにこれ

ぐだぐだ曖昧論を繰り返すより
510の用途でトラブルが発生するツールを上げた方が有用だろう。
トラブルが出ないものはいくつか挙げられた。

>>510 が好きなのを試してみて、使えたかどうか報告してくれると有難い

>>528
515に書いたようにsvnで満足しそうなのでこれでいいかなと思っています。
何か問題が起きたらまた相談に来ます。

>>527
たぶん、ビッグエンディアンのマシンでBDBで作ったSubversionリポジトリをコピーしてリトルエンディアンのマシンに持ってくと壊れると思われ。
そういう特殊ケース以外は結果的に問題ないんじゃね? 根拠はないけど(ぉぃ

>>530
マジで？

DBDはバージョンアップのたびにアップデート必要だったり散々な思い出しかないわｗ
svnのBDBってかなりヤバイイメージ･･･

頼むから、同じ過ちを繰り替えささないで、とは思う

BDBの存在意義がわからない

今じゃFSFS使えば困らないからね…と思ってたがRubyをsvnsyncした時は心が折れかけたｗ
BDBの代わりにSQLite使ったらどうなるんだろうか

svnのバックに汎用のRDBをもってこれないの？

svnのバックエンドにgitってのはあるみたいね

JavaEE5を用いたシステムで
ソースとEAR等のアーカイブ以外に、
クラスもバージョン管理したいって上司が言ってるんですが、
そんなこと普通するのでしょうか・・・
皆さんのご経験をお聞かせ願えますか？

>>536
しない。

ビルドターゲットの違いを心配してるんだろうけど
わざわざ、クラスの管理はしない。
もしするんだとしても、開発用とは分離したレポジトリだな。

>>536
流石にそんな経験はないな。

>>536
むしろ、してはならない類いの一つ。

>>537,538,539
貴重なご経験教えて頂き、皆さんありがとうございます。
何とか上司を説得してみます。

必要最小限の機能しか使わないならcvsでいいのかな

流石にこれから導入ならcvsよりはsvnじゃね？

git だろ

俺もsvnを使う。
cvsはディレクトリの移動に対応していないし
同時にコミットしてもファイルごとに別のリビジョンになるので
他のSCMに慣れた今では気持ち悪い。

>>543
cvsとgitはぜんぜん別物じゃん

LinusがSVNは糞ってゆってた

CVSは論外ともな

mercurial か bazaar だよ

CVS使うぐらいならSVN使った方がいいよなぁ。
上位互換って感じだし。

分散系はどれが主流になるかわからんから
今のところ趣味レベルでいい気はするわ。

今から使うならCVSでなくSVN使うけど、SVNはタグとブランチの扱いが不満。

>>550
svnのタグってコピーだもんね。

>>546-547
Linux Kernelの開発には機能不足でまるで使えないそうな。
まぁそうだろうなとは思う。
あそこまで大規模かつ分散した開発形態なんて、CVSが出た頃には考えもつかなかっただろうし。

>>541
何が必要かによるんじゃない？

用途によってはRCSで充分なこともあれば、gitじゃないと困ることだってある。

>>552
gitの入門を読んだ限りでは、自分や他人の作業について、非同期性を如何に上げるか(如何に妨げず/妨げられず、かつ如何に追随する/させるか)という点を重視してる感じがする。
だから、そういう部分に需要がない場合はgitは使いづらいんじゃなかろうか。

とは言え、新規に立てるなら、コミットの単位がトランザクショナルじゃないCVSは今さらありえないけど。
先日ものすごく久々にCVSを使ったとき、「この差分はどこを起点にしていると説明すればいいのだろう」と一瞬固まったもんな。

CVSに誤解があるようなので弁護すると
コミットするとき関係するディレクトリに書き込みロックをとるのでトランザクションになっている。
CVSで問題なのはトランザクションで更新されたファイルを後から調べる方法が用意されてないところ。

Winで色分けして表示してくれるコマンドラインのdiffってないかな。

>>556
vimdiff

他のメンバーに、ちょっと試したいことがある時とかはすぐブランチ切れって言ってるんだけど、
面倒らしくなかなか切ってくれない。
trunk一本でやろうとしてて、試行が上手く行かなかった結果をコミットしたくない、とか言い出す。
そのわりに、上手く行かなかったのってどんなことやったの？ってレビューするときに、コミットしてないから忘れた、
とか言い出すw

そういうのは、ブランチ切っておいて、間違ったらコミットはするけど、そのブランチは放置しとけばいいって言ってるんだけど
どうしたもんかね。

svnって分散系に比べてブランチきるのがすげー面倒なイメージは確かにある
分散だったら極端な話、cloneするだけでそれでも一応ブランチになるし。

>>556
おれはむしろ、色分け表示してくれるGUIのdiffビューアがほしい…

winmergeじゃ駄目なん

>>558
同感
実装が終わってないといって何週間もコミットしてくれなくて困った
進捗状況がまったく見えないし間違った方向に進んでいるかもしれないし
書きかけのコードをコミットさせる工夫はある?

>>558
Subversion＋MQで使えばいいと思います

安易ブランチ切るなって所もあるけどな

ブランチ切るのめんどくさいって言って言う事聞かないやつには
svkでも他の分散型でも薦めたところでめんどくさくて使ってくれないだろうな

> 書きかけのコードをコミットさせる工夫はある?

うちは、そういうのやってないなー。

チケット駆動開発してて、切りのいいところでコミットしてほしんだけど(コミットログでチケットに関連付ければいいし)、
あるメンバーはタスク1個につき、1コミットかもしくは、まとめて数タスクやってコミットとかする
そのメンバーとはプロジェクト一緒じゃないからいいけど、もうちょっとまめにコミットしようぜって言ってるｗ

俺は、なるべくバンバンコミットしてる方だけど。
ただ、切りがよくても動かないコードはさすがにコミットしづらい。それこそ、ブランチなんだろうけどね。

>>558
ちょっと見てみる

> ただ、切りがよくても動かないコードはさすがにコミットしづらい。それこそ、ブランチなんだろうけどね。

ごめん、このくだり意味がわからんな。俺も読み直して意味がわからん

>>563
そうそう、面倒くさがってしまうもんだよねー

以前、TortoiseSVN使ってもらってた時も、あるメンバーがなかなかコミットしないようになったから、
なんで？って問いただして後ろから作業見てたら、
OS再インストール時にsshのパスワード入力をある程度省略するpageantの導入してくれてなくてだな
(ちゃんとインスコ方法とか俺社内マニュアルに書いたのによー)
何かことあるごとに、パスワード入力しなくちゃならないのが面倒なようだった。

TortoiseSVNで素のsvn+sshだと、コミットウインドウ開くとか、リスト取得とかログ見るとかコミットするとか、
何かするたびに頻繁にパスワードを聞かれて、俺でもいやになるわｗ

朝一と昼に cron とかで自動的に nightly ブランチに突っ込ませてるよ。
最初、昼だけだったんだけど、
朝一は今日やる作業を戻したい時用に使ってる。

めんどくさがる割にコードレビューには参加してくれるんでしょ
やり方の問題なんじゃね？

ちょっとお試しでのコミットがtagsでやって欲しいけど

>>558
svnはワーキングコピーをリポジトリに直接コピー可能だから、事前にブランチ作らなくても良いのにな。
trunkで作業してて、ブランチにしたくなったらワーキングコピーをブランチにコピー、その後スイッチ。

進捗見せないとか、成果物残ってないやつは寝てるのと同じだから、俺は直ぐクビにしたい。
ソースもドキュメントもSCMで管理されていない状況は許さない。

>>565の後ろの話で何がいいたいかというと、ちょっとした面倒なことでも
導入や運用のマイナスになるよね、っていいたい。

仕事だから覚えろ、とか使え、ではなかなかすまない話。人は、面倒なら使ってくれないよな。

そういう意味あいで、Dropboxってバージョン管理の利点を学ばせるのにはよかった。
全然ソースコード管理には向かないけど、「履歴が残るのは便利だ」ってのをあまり面倒なく実感できるからね。

うちのバージョン管理使ってない部署で、Dropboxが一気に広まってから、
急に、バージョン管理ソフト使おうと言い出したことがあった。
(俺が同時にVCS導入すると便利だよ、といつも啓蒙活動していたせいもあるが)

連投スマソ

基本的に>>558のプロセスは糞だと思うに一票。
つか、研究かなんかか？

それは言えてるな。
svnよくわかってない人間に>>558みたいな操作はやらせたくないし。

開発の人はsvnの凝った操作を憶えるのが仕事じゃないから、「こうやればできる」
って言っても「そんなわけのわからん操作が必要なツール使うのがおかしくね？」
ってことになる。

うちはそう言う事をやらせたいんならドキュメント書けって言われる

書いても見てくれないんだけどね

シッタカでブランチ切ってマージできないんですけど
って毎度泣きつかれるのも面倒だぞw
頼むから trunk で作業してくれとうまく丸め込むのに苦労した

うちなんてバージョン管理を俺しか使ってないという…無意味にもほどがある。
バックアップ代わりになるから一人でも使ってるんだけどね。
二人以上で同一のファイルに触るなら、バージョン管理したいんだけど、小規模すぎて使う必要ないんかな…。

一人でも慣れちゃうと無いと困るけど
ひとそれぞれかな

>>574
そういう人にはbazaarですよ。
うちでは個人ではローカルで更新続けて、コンパイル完了で中央で上げるって運用している。

俺も一人でも使ってるなぁ。
試し事してるときに、直ぐに戻せるってのは嬉しい。

タイムスタンプ信者がうるさくてSVNに移行してくれない人が数人いるかな

>>578
チェックアウトやアップデートで
mtimeをコミット時刻にしてほしいという人はいたな。
昔ながらにfind -mtimeで変更ファイル一覧を取得したかったらしい。

自動焼人 ★　＝　自動保守 ◆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/
にて自動焼人 ★までご連絡ください

Mercurialのスレ立てたので宣伝
http://pc12.2ch.net/test/read.cgi/tech/1251208950/

ちょいとお聞きしたいのですが、
とあるプロジェクトAが匿名でとってこれるsvnで用意されてありまして、しかしながら、私はコミット権はもっておりません。

その状態で、そのプロジェクトのパッチを作ったり、弄ったりしつつ、自分の弄った範囲をバージョン管理したいのですが、
よい方法はありませんでしょうか？

通常、分散であれば、cloneとかしたものは、ローカルならコミットできると思うのですが、
svnで匿名で持ってきたものはコミットできませんよね？

ただ単に、svnで匿名アクセスしローカルにもってきて.svnディレクトリを削除し、
ローカルのgitかhg(bzr)に突っ込む、
つまり、単純にソースのみ持ってきて、過去のバージョン管理を破棄し、新たに分散管理するという方法だと、
利便性がない、と感じています。

何かよい方法、ないものでしょうか？

git-svn

bzr-svn

>>582
svk

>>585
いまさらsvkは無いだろ・・・

hg convert

>>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にコミット権を持つ人の作業

とりあえず、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も試してみる

コピペミスった・・・

> リポジトリは マッスルリベンジャーです
リポジトリは、http://rubygems.rubyforge.org/svn/ です。

どういうミスだよ

ﾜﾛﾀ

>>588
hg converでsvnからとりこんでhg mergeでいける。
あるいはMQをつかう。

>>593
すまん、svnへのpushが要件に含まれて居ないことに今気づいた。

>>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が使えると思います。

あと、マッスルリベンジャーってなに？ｗ

bzrのミラーもあるよ
https://code.launchpad.net/~vcs-imports/rubygems/trunk

じわじわくるな、マッスルリベンジャー

しかしこれももはや年がばれる系に入ってきてるのか

何度見ても笑ってしまう

最高だｗ
俺もマッスルリベンジャーの名に負けないソフトウェアを作りたいと思う。

>>595
おお！githubにミラーがあったんですね！
試しにforkして、cloneで引っ張ってきたらあっという間にローカルに持ってこられました。
自分とこでコミットしたり変更して、パッチ作って送る分にはgithubでいいのかな・・・。

git-svnのやり方も紹介していただいてありがとうございます。
後で試してみたいと思います。

>>596
launchpadにもミラーが！サンクス!!
こういうときには、ミラーがあると助かりますね。


> あと、マッスルリベンジャーってなに？ｗ

・・・たぶん、キン肉マンの動画いろいろ見てたからクリップボードにはいってたんだと思う・・・
YouTube - キン肉マン・キン肉星王位争奪編°マッスル・リベンジャー
http://www.youtube.com/watch?v=sBv49dL2fGs

git-svn って >>588 みたいに一つの svn リポジトリと不特定多数の git リポジトリの間で
分散バージョン管理できるの？
それとも、svnを中央リポジトリとして使わないといけなくて、git <-> git 間でやり取りしたリビジョンと
svn上のリビジョンの整合性は取れなくなる？

>>601
git-svnは、svnリポジトリを中央にしないとダメだと思う俺の知る限り。けっこうこれキツい。
git同士ならぐるっと回って上流から戻ってきたコミット（内容は一緒だけどハッシュ値は違う）
があっても、rebaseした時にいい感じに上流のを採用してくれたりするんだけど、
svn <=> git<->git<->git という感じだと、すべてのgitはsvnにrebaseしていかないといけない。

Subversion1.5のmerge-trackingを利用して、mergeコミットぽく解釈したりできれば、、、とか
妄想するんだけど、できないもんかね。

svkが終了したので、svn <=> svn間のマージもどうしたらいいもんか、悩み中。

>600
>launchpadにもミラーが！サンクス!!

何故かlaunchpadを「 レ オ パ ル ド ン 」と空目してしまった。
明日眼科逝って来る。

なんだこのスレ肉マニアのおっさんばっかりかｗ

>>604
レオパルドンは肉じゃなくて、たぶん…

まぁ、止めておこう…

　　　　ﾍ⌒ヽﾌ
　　　（　・ω・）　�d
　　　/ ~つと）

　||　　 ／￣￣￣￣￣￣￣￣￣￣￣￣
（＋）＜　次峰レオパルドン逝きます！
　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿

　　　||　　　　 ／￣￣￣￣￣￣￣
　　（＋）　　＜　グオゴゴゴ！
　/（ ┴ ）ヽ　＼＿＿＿＿＿＿＿
　　ヽ＿/
　　／　＼三　)))

　　　　　　　　　　　　　||　　　　 ／￣￣￣￣￣￣￣
　ﾉｰｽﾞﾌｪﾝｼﾝｸﾞ!! ＼（＋）／　＜　ぎゃあぁぁ！
===============⇒※；）　　　＼＿＿＿＿＿＿＿
　　　　　　　　　　　 ヽ＿/∴．:
　　　　　　　　　　　 ／　＼∵;.;

　　　　　　　　　　　ミ
　　　　　　　　＼　　 ／　　ｽﾞﾝ!!
　　　　　　　　　二二＋＝
　　　　　　　　／　　 ＼

うざい

>>602
svn merge で cherrypick merge とかどうなん？
bzr-svn でも bzr merge で cherrypick merge できるし。

IBMのRationalClearCase（クリアケース）って言う
バージョン管理システムって相当酷いものだと聞いた。

http://www-06.ibm.com/software/jp/rational/products/scm/cc/

担当部署の人間の話だと
値段は凄まじく高い上に、制限が多いとかでほとんど使い物にならない詐欺に近い製品って話だ。
IBMのぼったくり商法に騙されたのかも知れないけど、
うちの会社もこのRationalClearCaseをCVSから一部切り替えて運用し始めてしまって引っ込みが付かなくなってしまった。
「CVSは無料だし機能的にもよっぽど使いやすい、有料ならVSSを使った方がマシ・・・」とは担当者談。
そもそもこのIBMRationalClearCase（クリアケース）はメジャーなソフトではないので、設計や導入にもかなり苦労するようだ。
CVSからの移行の工数を聞いただけでぞっとした。
こんなの売りつけられたなら、その会社はIBMのカモにされてると思ってほぼ間違いないんじゃないかと思う。

>>610
元々のRationalがIBMに買収される前はそれなりだったらしいが、
買収されて以降殆ど更新されてないのだろうからいい訳がない。
つーか、企業で導入って、どんな情報弱者だよw

無能担当者とその暴走を抑えられない体制はどうでもいいとして。
IBMにしてみれば顧客が居るから捨てられないんだろ。
Linuxを推し進めているのにAIXの開発から手を引かないIBMらしいエピソードだね。

つーか、IBMにとっちゃRationalTeamConcertとかRationalAppScanが欲しくて買収したらおまけについて来たようなもんだろ。

評価もせずにホイホイ導入するのか
普通の会社なら潰れる

評価版もあるのにねぇ。

うちは弱小ソフトハウスなので、その辺の事情ってよくわからんのですが、
評価はともかく(いや必要だけど)、評判とか情報が少ない製品をなぜ選ぶもんなんでしょうか？
いくら商用で、サポートとかあっても、そんなんなら、まだ情報が大目のOSSとか選びたくなるもんですけど。

>>616
・自分より詳しい奴がいるのが嫌。
・コンサル/営業に吹き込まれた。
・キックバックをもらった。

「あのIBMが出してる製品なんだから、間違いありませんよ」
なんて言われて真に受けちゃったとか。

>>611-618
IBMRationalClearCase（クリアケース）なんて採用する時点で
上層部の人間が情報弱者（プロダクトの詳細も知らない、実際の現場の内情も知らない）というのは認めるが、
パートナーのIBMにすすめられてしまったら断れないという政治的な理由もあって、
一度決まったらトップダウンで話が進んでしまうんだよな。
いわゆる、上層部双方が自己満足して、後々になって現場だけが苦労するパターン。
IBMRationalClearCase（クリヤケース）がIBMに買収されてからというもの
更新もなく将来性が全くなくなったプロダクトになり下がっているのに
敢えてリスクを冒す必要があるのか？とか、
今までCVSやVSSで問題なく運用できているのに、
この不景気に無駄な資金をかけてまで果たしてやる必要があるのか？ということが問題になっているみたいだ。
CVSやVSSの開発やサポートが終了するから移行しなければならないというような必然的理由があるならまだしも
すでにある程度シェアを持っているCVSやVSSみたいなメジャーソフトが早々になくなるわけもない。
今までならCVSやVSSはどこの部署でも使っているから新たにバージョン管理を構築する際もハードルは低かったんだけど
IBMRationalClearCase（クリアケース）は超マイナープロダクトだから、
メンテナンスをする人員も新規に育成しなければならないし、
他部署向けの勉強会やらでコストだけが発生しているみたいだ。
今は、一部の部署でIBMRationalClearCase（クリアケース）になっているんだが、
他部署もそこに相乗りしろという話になってきているらしく大迷惑を被っている。
うちの部署に限って言えば、IBM製品はホームページビルダーやノーツを導入させられた経緯があるけど、
もしクリアケース導入ということになるとインパクトはでかいかも知れない。
というか、みなさんが言うように、クリヤケースはプロダクトの質が悪すぎるので積極的に使いたいとは思えない。

わかった！

git-clearcase とか、 bzr-clearcase とかを作って、
自分たちは、好きなSCMをつかって、うpするとき clearcase にすれば良いんだ。


あっ、そうか！！

っていうか、cvs-clearcase とか作れば、今まで手順そのままで、
うpするときだけ、clearcase に…

>>619
そういった分野では、今でもCVSやVSSが主流なんでしょうか。
gitやbzrとは言わないまでも、せめてSubversionぐらいにはならないのでしょうか。

これ買ってもらえ
http://www.clearvision-cm.com/clearvision-products/clearcase-and-git-bridge-cc2git/ash_flypage.tpl.html

CVSのところは某有名SIerを含めて未だ未だ多いよ。
VSSは流石に減ってきているようだけど。
皮肉なことに、逸早くCVSを導入したところほど移行できなくなっている傾向がある。

IBMのSynergyっていう構成管理ツール、使ったことある人いませんか?

>>619
現場の意見虫で、パートナーの提案をはいはい聞いちゃうのってすごいなー。

例えば、パートナーが「アナルセックスがしたい」と言い出したら、はいはいとケツ突き出すんだよなあ。
あげくに、パートナーが「スカルファックしたい」とか言い出した日には・・・
考えられねえ・・・

>>625
ケツ突き出すとかは論外だけど、>>619みたいにパートナー製品を持ち上げることによって
受注が見込まれて事業が継続できるのなら、会社組織としてはしょうがないかもね。
利益が出せなければ事業縮小してバージョン管理どころじゃなくなるとか。
そういうのを肯定するわけじゃないけど、そういう弱い立場の事業経営をやらなくてはいけない場合も
現実としてあるのだろう。

>>625
何も考えずに批判する立場って楽だよね。

まるで野党だなｗ

バージン管理システムってなんかヤラシイな・・・

むしろ肯定するためにあえてあのように書いた可能性もあるが
626は大人だな。

共通部だけCVSやSubversionにしといて個人個人は分散系の使うって方法もある

冗談でいったんだけど(´･ω･`) ギャグ通じてない・・・

>>631
そういうふうにやってみたがコミットが二度手間になって面倒くさくて
メリットがかなり薄くなってしまうように感じた。
gitかhgに余所のリポジトリ/ディレクトリとコマンド一発で同期してくれる
ような機能ってつかないものかな

>633
二度手間ってローカル分とリモート分ってことだよな？
これを分けない上で分散型が得るメリットってなんだろう？

>>634
commitとpush+pulllじゃなくて
1プロジェクトがsvnとgit/ghに分かれるのがいやといっているのではないか

>>633
git-svnとかhgsvnではなく？

欲しいのはgit-svnのようなものなんだけど、中央リポジトリがsvnやcvsのような
メジャーなものじゃないからgit-svnみたいな便利なものはないし誰かが作ってく
れることも期待できないんだ。
でまぁそういう理由で余所で更新され続けるディレクトリをあまり手間をかけずに
上手く同期してくれるような機能が組み込みであればなぁと。
まぁそんなんじゃ何かの拍子に壊れてどうにもならなくなりそうなのでほんとに
欲しいのは「git-svnの作り方」みたいなドキュメントかもしれない･･･。
ちょっと言葉足らずで誤解させたようですまんかった。

>>619
なかなか縁がないアプリだし、価格がいくらなのかは全く知らないが、Clearcaseっつーのが糞ソフトだということはよーく分かった。
そもそもIBMがそんなもんを出してることすら知らんかったわ。
まあ、フツーに考えてCVSでいいだろ。
しかしうわかたの連中ってどこまでお馬鹿なんだ？
ネット検索して製品情報ぐらい集めるだろフツー。

>>632
それはギャグじゃなくて皮肉だ

rational と言えば、有用なのって purify くらいだと思ったけど…
rational の BTS 使ったことあるけど、あれもひどかった。

>>640
Roseは？
これがメインだと思ってたが。

>>641

さらば「Rational Rose」、買収製品に順次移行へ - ニュース：ITpro
ttp://itpro.nikkeibp.co.jp/article/NEWS/20081007/316339/

RationalRoseなくなったら
もはやRationalじゃないじゃんって感じだね。
つか、テレロジックのRhapsodyってのはどうなのよ？
RationalRose無き後は
RasionalClearCaseを看板にすればいいかもね。

VisalTestバリバリの俺が通りますよ

今って何が流行なの？

みんなで書いてるソースはサーバーにsvn+sshと
なんかTracとか言うwiki連動させて
wikiでバグとか要求管理してんだけど

個人でやる場合はトータスSVNで普通に自分のマシンにリポジトリ作ってるだけだな

TracのWiki使ってるとかマゾヒストか

>>646
15人くらいのプロジェクトだけどガチで書いてる
マジめんどいから俺は嫌なんだ・・・

まあバグをあげるとき、要求をあげるとき、ToDoをあげるときって
wikiの雛形は決まってるんだが
いちお、svnと連動もしてるしな、その機能使ったこと無いけど・・・

バグ管理は何が流行なんだ？もちろんフリーでだ

普通はチケットの方を使わないか

>>648
あー、チケットももち使ってるぞ
マイルストンに向けて、openなの何個みたいな感じで
ただ、詳細な情報を書くときにwikiになるんだわ、これがだるい

Tracのwikiのクソさには定評がある
RedmineだろJK

>>650
さんくす、Redmineな
軽く環境作ってみて、よさげだったら提案してみるわ

詳細な情報もチケットに書くのが普通だと思う
添付ファイルとかつけられるでしょ
Wikiの部分はサーバ設定とかそういう共有情報をまとめる所じゃね

うちはRedmineでやってるが、何故チケットを使わんのだｗ Tracのチケット管理はそんなにクソなのか？ｗ

>>646, >>650
そうなの？Trac Wikiの方が書きやすいと思うけど？どの辺が気になるの？
好みの問題もあると思うけど、textile記法とmoinmoin記法ではmoinmoinの方が
Wikiコードをメールに貼り付けた時に読み易いし、いいと思うんだけど。
(慣れが大きいと思うけど)

Wikiめんどくせとかいうけど、
用語定義とか、まとめに使う分には参照・更新両方のバランスを考えるとかなり効率的な部類なのでは？

Tracは基本的に良いけど、Wikiの編集はローカルでテキストエディタでしたい。
Wikiの内容を分散バージョン管理したい。

今、Launchpad4の要望調査で(Bazaarでバージョン管理された)Wikiというのが
要望高いから、moinmoinのバックエンドをBazaarに置き換えたのが開発されないか
wktkしてるところ。

>>654
うちはRedmine使ってるけど、Wikiはページ名を決めるのが面倒くさい。
イテレーションごとの仕様書とかはリポジトリに突っ込むから、
そっちの補足情報とかはWikiではなくチケットに書いてる。

gitの質問よいでしょうか？
指定のリビジョンの指定のファイルを取り出したいのですが、どうしたらよいのでしょうか？
git checkoutはなんか取り消す？というような記述で違うようですし・・・

git show?

Trac の Wiki が弱いのはわかっていますが、
うちの会社では未だに {{{ほげほげ}}} でチケットを書いてくるような池沼を相手にしなきゃいけないので、
Trac とか何とか、それ以前の状況でつ。 (鬱

ちゃんとpreformatted textの指定してくれるだけましじゃんw

>>659
あー、全文preで書いてんのかｗ　見るねそれｗ
textileとかmarkdownとかはてな記法とか、いっぱいありすぎて頭こんがらかってくるけど、
どれもやりたいことは数パターンで、使ってるうちに憶え、使わないうちに忘れる。
最近trac使ってないから忘れちまったなぁ。

gitはギトギトしててキモイ
いかにもオタソフトって感じがダメダ

消えてなくなれ

たまに居るね〜、アンチGit。なんだかなぁ。。。

>>656
うちも仕様書等の補足情報はTicketに記述するようにしてる。仕様書作成タスクとして定義する感じで。
確かにWikiページ名はある程度課題を走らせてからでないとしっくりこないですね。

Ticketとの比較という意味で、WikiのいいところはTrac上の記述内にWikiページ名である時に自動的にリンクが生成されるところですね。
なるべくWikiには再利用される可能性が高い用語を定義するようにしてるんだけど、
Ticket内の記述が自然にマークアップされるようになるとWikiってすげーって思える。

>>659
人によっては改行が全くない状態で入れられたり。。
そういう人が多数派にならないように地道にまともな記述を増やしています。

そろそろうざいんですが

そういえばDAVは動きは無いのかな？
記憶が確かならVはバージョニングだったハズ

そもそもBTSスレってなかったっけ、と思ったらあった。
http://pc12.2ch.net/test/read.cgi/tech/1244347242/

BTSスレ池

ファイルが巨大だったり沢山ありすぎるような場合は
git以外の選択肢はないのでしょうか

別に何でもいいと思う
巨大ってのが1ファイルでギガとかじゃなければ

squidのキャッシュフォルダーをまるごと管理しようと思っているのでギガのファイルもあるかもしれないです

>>671
なんか面白そうだな。archive.orgみたいなものを作るの?

>>671-672
ついでキャッシュの情報をp2pで共有できたら、
ペッパーランチみたいな事件で大活躍だな

P2Pと相性よさそうなのはdarcsか？しかし日本語がなあ

分散バージョン管理をバックエンドにしたp2pのwebアーカイブ(キャッシュ、魚拓)みたいなのかｗ面白いなそれ

>>669
gitでも何でも厳しいだろ。ｊｋ
ファイルコピーだけでもかなりの時間が。

ポスグレのblobなんかで自作したほうが早い希ガス

git か何かはバイナリも差分で管理しなかったっけ

gitは差分じゃなくて圧縮してまるごとだから、逆に向かないような

バイナリの扱いは、
svnはxdelta
cvsはそのまま
gitはまるごと(バイナリ以外も)
ほかは知らない

そうか。何かバイナリを差分で扱うのがあったような。BitKeeper?

>>680
>>679にあるsvnのxdeltaってのはバイナリ差分(のアルゴリズム)だよ。

>>679
> gitはまるごと(バイナリ以外も)

　 ｲ｀ﾍ
　/: :| ヽ
/ : :/　　ヽ　＿＿＿　　　_,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡　/
　　　　　 ( : : : : : : : : : : : : : : ｀ゝ　 /
　　マ　　r::/: /: : | : : : : : : : : ::＼ /
　　 　 　//: /: : : |: : | |: : |: _: : : :ヽ
　　ジ　 {/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
　　　　　〉 ,‐-‐､｀|7　|| |_::|,_|: : :|:::|: |
　　で　／ r:oヽ`　　 　/.:oヽヽ: :|: | :|
　　　 　{　{o:::::::}　　 　　{:::::0　}/: :|N
　　っ　 |　ヾ:::ソ　　　 　ヾ:::ｿ /|: : |
　！？ ヽ::::ー-..　／ヽ　..ー-::: ヽ::|　r--ッ
-tヽ／´|｀::::::::::;／　　 `､ ::::::::::: /: i　}　 ＞
::∧: : :|: |J　　 ＼　　 ／　　 ／::i: | /＿ゝ
. ＼ヾ: |::|｀ - ,, ___｀-´_ ,, - ´|: : :|:::|
　　 ヽ: |::|＼　　　 ￣/ /|　　|: : :|: |

クリアケースは糞

>>682
それでもリポジトリのほうが小さかったりするけどね。
例えばlinux-2.6はソースが404M、全履歴含むリポジトリが352M。

まるごとつーても、packはあるからな。

>>685
packって
差分を取り出すかわりに
複数の履歴を一まとめに圧縮することで重複をなくすってことか?

そろそろCVSから移行しようかと思うんですが、
subversionとmercurialのどちらがおすすめですか？

そう言う聞き方をするバカにはSVN使ってれば良いと思います

そう言う聞き方をするバカにはCLEARCASE使ってれば良いと思います

git がいいと思うけどなー

集中型に比べた分散型のメリットがわからないのでsvnのまま現在に至る。

>>687
CVS→Subversionの方がCVS→Mercurialよりも覚えることが少ないので
まずはSubversionを使うのがいいと思います。

フリーでバイナリー差分ができるのがsvnのみってことでいいの？

>>693
バイナリ差分って具体的に何？
バイナリファイルのdiffをパッチとして送るってこと？
それともリポジトリの格納形式を気にしてる？

svn updateしてdllとか更新されたときにmergeって表示される時があるけど
恐いから削除して更新し直してる

>689
cleacaseってそんなにいいの？？

Rubyでできたオブジェクト指向なバージョン管理システムはありませんか？

そういえばRuby製は聞かないな。
オブジェクト指向なVCSってのは何を指してるのかわからんが。

>>691　俺もそう思う。
分散型といっても最終的にはマージしなくちゃならないんだから、差異が多くなる前にマージしないと競合が激しくなるんじゃないのかな。
こまめにマージするなら集中型と変わらないんじゃないかな？

>>699
分散型は、よくあるコミット権云々のしがらみから解放される。
パッチ送ったのになんで取り込まないんだよ云々からも解放される。

誰でもコミット（push?)できるの？怖くない？

>>701
自分ちにコミットしても誰も怒らないよ

それなら集中型でも俺んちリポジトリを作れば一緒のような気がする。
元が更新されても差分を俺んちリポジトリにマージすればいいんだし。

3way mergeうんぬん

>>704なるほど。
分散型はmergeが偉いという認識でいいの？

>>703
その通りなんだが、集中型はもともとそういう用途向けに作られてないし、
そうやって俺んちリポジトリにマージしながら使うのって、
『集中』してないよな…
そういう用途には分散型が適してる。

>>679 >>684
本当だ。700kbのexeバイナリつっこんで、毎回コンパイルするのを想定して、バイナリエディタで弄ったのをコミットしたら、
毎回圧縮されたと思わしき、400kbずつリポジトリが増えていった。

githubにexe突っ込むのやめないといけないな、これは。

>>703
使い方がまさに分散型なのだがｗ

実効ファイルの差分ならgoogleが凄いの出してたな。courgetteってやつ。逆アセしてdiff取るらしい。

>>709
Chromeの更新に使ってるやつだね。
確かに逆アセまでやるところがすごいと思ったわｗ

>>709
Google Chromeのソフトアップデート用圧縮技術Courgetteが面白そうなのでちょっと考えてみた ([email protected])
http://blog.browncat.org/2009/07/google_chrome_courgette.html

これか。
逆アセしてテキストで差分とる？だろ、パッチあてるときどうすんのかな。
パッチあてるexeを逆アセして、パッチあてて、またアセンブルするってことか？

完全な逆アセンブルまではしてないんじゃないかなあ。
単なるバイト列じゃなくて、各命令の境界やオペコードとオペランドの境界を見た上で
いろいろやるってことじゃないかという気がする。
オペランドに即値やアドレス指定がある場合にも何かやるんだろうけど。

>>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で作る利点は無いな。

Ruby界隈であんだけgit広まってるわけで、わざわざ作る理由がないな

git logしたときに，コミットメッセージが長いとターミナルに全部表示されないんだけど，
長いメッセージを自動で折り返すようにするにはどうしたらいいの？
ちなみにcygwin上で使ってます．

>>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で動くようになる日はいつだろう。

>>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はいろんな場所で継続して
使われてるだろ。

>>717
最近のRubyしか知らない人なら、大きな差と言えば1.8.6前後や1.9の差
くらいしか知らないだろうから、それ以前の差異を軽く見てるかもしれな
いけど、それ以前からRuby使ってるなら>>716みたいなたわごとは言わ
ない。1.8系間での互換性のなさは身を持って知ってるはずだから。

>>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で入ったの？

>>719
わかっててきくな。

お前らそろそろアンチRubyスレにいけ。鏡で顔見ろ

>>718
>1.8系間での互換性のなさは身を持って知ってるはずだから。
具体的にどうぞー！

>>720
なにこいつ、具体的な内容なにひとつわかってないのに罵詈雑言まきちらしてたわけ？アンチRubyキモー！

これぐらいで満足していただけないでしょうか？
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

それ読んだのか？基本的にバグフィックスと、軽微な仕様変更だけじゃないか。
互換性がなくて困るほどの仕様変更ってどれさ？1.8.2から1.8.7までをサポートするうえで困る仕様変更って何？
>>718
>1.8系間での互換性のなさは身を持って知ってるはずだから。
1.8.2から毎日使ってるけど、互換性のなさで困ったことはRuby本体ではない（Railsはしょっちゅう）。
おまえが困った非互換性ってどんなのがあったの？まじで教えてほしいんだけど。

ruby は1.9.2 がstableになった後、gemが安定し始めたら、test始めていいんじゃないかと。
そこそこ混乱するだろうけど、収束は早いのではないかと。

Python は外部ライブラリに頼る物は、世代移行や後方互換が難しい上に、
多方面に影響するので、php4、php5の様に、2.5.4 と3.1.1は別枠で投入された方が良いと思う。

pythonとrubyの戦いは言語スレでやってちょ。

スレタイよめよ・・・

>>720-726
誘導
【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1248487404/

haskellでいいじゃん

Python 3.0 は過去のしがらみを捨てた大掃除なんだから、比べるとしたらRuby 1.9じゃなくてRuby 2.0だろ常考・・・

Ruby1.6 の頃から使ってる俺拡張ライブラリがあるけど
ヘッダが #ifdef だらけでえらいことになっとるｗ

StringPtrとかARRAY_LENとかrb_io_tとか

どっちもどっちのくだらない言語のはなしはいいよ
スレタイ2回読んでくれ

日本語のテキストって、utfにしとけばバイナリじゃない扱いになるの？

>>733
バージョン管理システムによっても違うと思います。
自分が使っているSubversion、Mercurialは
UTF-8はテキストとして差分表示できます。

>>733
Subversionは、確実な方法としてversioned propertyというものを
設定できるので、それで mime-type やら encoding やらを設定しておけば良い。
hgとbzrは、今のところファイル内に '\0' バイトがあるかないかでバイナリファイルか
否かを判別してたと思う。
bzrは将来的にsvnと同じようなプロパティをサポートする雰囲気。

>>735
> bzrは将来的にsvnと同じようなプロパティをサポートする雰囲気。
その点、hgは絶望的だ・・・orz

bzrはsvnと志向が似てる分、svnと同じように完成度が上がるのに時間がかかってる気がする。
もうすぐ2.0になってまともなリポジトリフォーマットがデフォルトになるけど、そのあとにもNestedTreeとか
HistoryHorizonとか、コピーとか、なんでこれがまだねーんだよという機能が保留されてる。

>>737
NestedTreeとHistoryHorizonについて解説よろしく

>>738
NestedTreeは、svnのexternal reference.
ツリー内に他のツリーを含める事。

HistoryHorizonは、git の --depthオプション相当。
古い履歴を切ることで、大きいプロジェクトを初めてチェックアウトするときに
短時間で出来るようにする。

今でも stacked branch とか lightweight checkout という機能があるんだけど、
これは古い履歴を見えないようにするんじゃなくて外部から取ってくる機能なので、
リモートからlightweight checkoutとかしたらオフラインで作業が出来なくなる。
gitのdepthはpushを保障していないけど、bzrはきちんと整合性を維持できる形で
実装したい気持ちはある。気持ちがあるだけで今のところ実装始まってない。

InkscapeのDVCS決めでBzr派とGit派が対立中。
http://www.nabble.com/DVCS-Discussion---Vote-to25430189.html

Mercurial + TortoiseHgの日本語パス及び
日本語ファイル名の問題ってまだ解決できていないのでしょうか？
（SJISというかcp932問題ですかね）
パッチが登録されているようですが、
このパッチが救世主になってくれるのかな？
ttp://mercurial.selenic.com/bts/issue1828

こんなんで、domain 取っちゃうのなw
ttp://bzrvsgit.com

>>741
まだ解決できてない。
fixutf8はフォルダでバグるし…早く何とかしてくれ。

bzr-hgがpushにも対応したら、utf8が完全に動くhgクライアントの出来あがりw
いや、マジでそっちの方が早い気が・・・

>>743
そうなんですね…。
ここさえなんとかなれば文句ないんですけれど。

NetBeansのIDEの組み込みのMercurial拡張がUTF8対応してるかもｗ

>>744
bzr-hgってバックエンドにhgのコード使ってたような…

>>747
うん、使ってるよ。
リポジトリを読むところはhgを使っても、それで取り出したUTF-8をBazaarがUnicodeとして
扱ってWindowsのUnicode APIを使ってファイルを保存してくれたら問題解決。
ある意味、fixutf8代わりにBazaarを使うの。
残念ながらまだpushできないから実用にならないけどね。

> 残念ながらまだpushできないから実用にならないけどね。

ダメじゃねーかｗ
でも期待したいなー
bzrがフロントエンドでBitbucket.orgとか使えるようになるかもしれないんだよね？

windowsでまともに使えるのは、いまだにsvnだけ？
hgなら日本語ファイルさえ使わなければ、ソースのコメントに日本語書いても大丈夫？

>>750
問題ない。さすがにファイルの中身については。
TortoiseHgでもちゃんとdiff見れます。

>>750
日本語ファイルでもWindowsのみで運用するなら次のバージョンでほぼ解決かも。
ttp://groups.google.com/group/mercurial-ja/browse_frm/thread/2a25b275f631cea3/1eda88c133016111?hl=ja#1eda88c133016111

>>752
おっ。そんなものが公開されてたのか。
win32mbcs.pyを入れ替えたらTortoisehg0.8.2でも日本語が通るようになった。
フォルダの化け文字についてはまだだめか。

>>753
うまくいったのは日本語ファイル名？
もしファイル名がうまくいったらフォルダ名でもいけると思うけどなぁ。

>>754
管理表.xlsって日本語ファイル名。
ちなみに化け文字が入ったファイル・フォルダを直接コミットしようとすると反応しない。

表
0x5C

VSSの誰かが触ってる間に絶対に触れないって仕組みが納得いかない
アップする気はないけどちょっと弄らないと動かないときってあるだろ
バカヤロー

よく考えないアホには一見正しそうな気がする仕組みだからねぇ
複数のファイルから成るプロジェクトだと気休め以下のゴミ仕様

日付フォルダーをいっぱい作ってる人って、なかなかバージョン管理システムを
使わないね。何でだろう？

聞いてみたら？　たぶん学習するのがめんどくさいからだろう。

>>759
日付フォルダーは目に見えるからわかりやすいんだろうな。
そもそもそういう人たちはバージョン管理システムなんてものを知らないだろう。

ブランチ作るのは仰々しい by新入社員

聞いたらこれでうまく行ってるって言うが、必ずどれが最新かフォルダ主に聞かないと使い物にならない。
日付が新しくてもリリース版とは限らないんだなこれが。

>>755
あー、そうそう。ダメ文字はあいかわらずダメなんだよね。
ttp://www.asukaze.net/etc/vcs/hg-fixutf8.html

>>755
直接っていうのは、エクスプローラでそのファイルを右クリックして、
TortoiseHgのメニューからって意味かな？
シェル拡張関連は右クリックメニュー、アイコンオーバーレイ共にダメかもしれん。
だけど TortoiseHg 0.8.2 と >>752 のメールに添付されてるwin32mbcsで
コミットダイアログから「管理表.xls」を追加したらエラー出なくて、コミットも問題なく通った。
win32mbcsを無効にしてやったらもちろん失敗。

>>764
完全にだめってわけじゃない。
ダメ文字を持つファイル・フォルダを右クリック→コミットの動作は出来ない。

bzr-svnってbzr branchのとき、changesetごとに何かデータ構造をメモリ上に作ったりする？
実メモリが少ないのでスラッシング起こしてbzr branchが終わらないwww

>>759
バージョン管理重過ぎね？
ソース程度ならできるけどソース限定な気がする
仕様書とか無理だろ超重い

1MB前後のレポート作成する限りではTortoiseSVNで管理しても全然重くない

>>768
プロジェクト全体をフォルダに毎回コピーするよりも、変更分だけをコミットするほうが断然軽いよ。
極端な話、ファイルを一回修正保存するたびにコミットしたって問題ないくらいだ。

>>757
Visual SourceSafe のこと？

誤解されがちだけど、オプションに
「複数ユーザによる同一ファイルのチェックアウトを許可」ってのがあるよ。
マージもできる

>>768いったい何ギガの仕様書ですか？
遅いのはLANのせいとか。無線LANだと凄く遅いぞ

>>771
マジか！
しかし、チェック入れてくれないだろーなー
デフォルトの糞さを呪うぜ・・・

>>772
３０ＭＢぐらいだよ
たったこんなんだけど数が増えてくるとすっげ遅いの
もう１０個もコピーしてっと半日作業だよ

>>767
バージョンは何？
bzr-svnのメモリ馬鹿食いが完全に直ったのは決行最近のバージョンだよ。

>>773
30Mを10個で半日というのはあまりにも遅すぎる。何か別の問題ではないか

>>773
とりあえず別のPCとか環境で試してみたらどうよ？

履歴の多さが遅さに直結してるような気がするなぁ〜

svnのdumpをsvnで管理したらどうなるかなと思って1G位のdumpをsvnに食わせて試したことも有るけど平気だったけどなあ。
何でだろう。

>>773
そもそもコミットする気がないなら、ローカルファイルのリードオンリー属性外せばいいだけじゃないか？
VSSはしばらく使ってないが、最近はそれだけじゃローカルファイルを編集できなくなったのか？

>>779
結構しつこく撥ねられるんだぜ

そういやTortoiseSVN使ってて、SVNレポジトリをNAS(LinkStation)に置いてたら妙に遅かったな
明らかにネットワーク的遅さとは異質だった

>>781 おいらのNASもそうだ。ファイルの転送速度は十分有るけど。新規ファイルの作成、伸張が遅いようだね。
NASにリポジトリ置くとローカルに比べてチェックアウトの時間は1.5倍、コミット時間は６倍になったよ。

>>782
そもそもHDDのスペックが貧弱なんじゃないの？

>>780
編集したいファイルが沢山あるってこと？
なら、ブランチを作成したほうがいいのでは？
vssはブランチ作成は簡単に出来た記憶がある。
でも、マージは面倒だったっけ？

VSSもマージは簡単だった

使ったことないけど、ではVSSが叩かれるのはなぜ？

昔vssで今svnだけどvssが悪いとは思わないな。
ロックによる方法が古臭いと思うけど、モジュール分けを丁寧にすればロック競合なんて問題にならないし。
しいて言えば、バージョンアップのニュースは聞かないし、高いって所かな。
あとはマイクロソフトだからじゃないか？

元々個人向けあるいは小規模チーム用の製品で MS 自身も使ってない上に
本当かどうかはわからないけどデータが壊れやすいみたいな話があったように思う

>ロックによる方法が古臭いと思うけど、モジュール分けを丁寧にすればロック競合なんて問題にならないし。

そりゃ悪いとは思わないだろうなぁ。

ロック型は複数ファイルを扱うツールやバッチファイルなんかと相性が悪い。
基本的にファイルを書き換える前にロックしなければいけないから、利便性の
ためにツールのプラグインとしてそのロック操作が組み込まれたりするが、そ
のプラグインが大抵親ソフトのバージョンアップについて行かないんで、バー
ジョン管理ツールの都合で開発ツールのバージョンがロックインされてしまう
ということが起こる。

>>788
MSがドッグフードしてないってのはわりと有名な話だよ・・・

MSの内部で
VSSを試したら直したはずのバグがいつの間にか元通りとか。
MS Projectで工程管理していたらスケジュールが破綻したとか。

まあ都市伝説みたいなものだと思うが。

これね
ttp://d.hatena.ne.jp/softether/20060202#p2
[質問]（中略）現在ではどういうツールを使ってバージョン管理を行っているか?
自社内で共通のソースコード管理ツールがあるのでそれを使う。
ソースコードの流れで、たとえばバージョン分岐などの管理もこれでうまくできる。

[質問] では、Visual SourceSafe などは使っていないのか?
Visual SourceSafe は使わない。あれはビギナー (初心者) 向けのソフトだ。

Team Foundation Serverがあるしねぇ。

Visual SourceSafe は 2010 もでないようだし
そろそろフェードアウトくさいけどね

IBMのクリアケース使いにくい・・・

bzr-2.0rc2-5 にTBZR 0.3 が入ったのはいいんだけど、シェル拡張部分だけなぜか
0.2の物が入ってて、オーバーレイされるアイコンが間違ってるorz

ちなみに、 TBZR 0.3 では、 >>561 の対策が半分入ってる。
THGと同じように、'unversioned' アイコンをキャッシュされてないファイルにオーバーレイ
表示してる。

Bazaarスレに書き込むつもりが誤爆した・・・スマソ

>>797
TBZRは中の人、一人で頑張ってるから勘弁してやってくれ。
つか、こんなとこでボヤいてないでバグトラッカーに報告すればいいのに。

>>799
あえて突っ込む必要があるのかわからんが、(>>797の)416 はTortoiseBzrのTop contributorなわけだがｗ

>>740の結果、InkscapeはBazaarを使うことになった模様。
http://www.nabble.com/DVCS-Vote-Tally-td25502877.html

LinuxやUnix専用のツールはgitで十分、クロスプラットフォームアプリの開発なら
Bazaar、っていう方向性になってきたのかな。
Mercurialは使いやすいgitという感じで、キャラが中途半端だな。

>>774
既知の問題だったんだ。情報どうもありがとう。
bzr-1.18 + bzr-svn-0.6.5 でダメだったから、さっきbzr-1.18 + bzr-svn-1.0.0rc1 で
やってみたけど、メモリ食いまくりは変わらずだった。
BTS見てみたら、メモリ消費関連でまだつぶせてないバグあるみたいだから、
もう少し様子みてみることにするよ。

>>796
クリアケースみたいなろくに書籍も情報もないようなアプリ使うなよ・・・
おとなしくCVSかSubVersion使うことをおヌヌめする

>>803
あちゃー。なんだろ。tdbが有効になってない場合とかにまだ穴があるのかな・・・

>>804
いやいや、クリアケースを使っているということは
恐らく使わざるを得ない状況にあるんだろう

クリアケースってCVSなんかと比べるとかなり後発なんじゃないの？
後発でもダメなソフトっていっぱいあるけどな

ダメでも、IBMと提携してるからとかいう理由で使っているんじゃね？

darcsからbzrにのりかえようとしてるんだけど
bzrはこんなことできます？

python2.5用に作ったコードを別ブランチで管理
python3.0用を別ブランチで管理

必要に応じてpython2.5からpython3.0への変更を残したまま
python2.5用に作った新機能をpython3.0にとりこむ
その逆もする

>>809
多分、cherrypickのことを言ってるんだよね。
まだ翻訳中だけどドキュメントはこちら
http://methane.sakura.ne.jp/bzr/user-guide/adv_merging.html

bzr重いね
windowsで使ってると何度も最新に更新ボタンおさないといけない

>>811
それはbzrが重いのかエクスプローラが重いのか、或いはbzrの周辺ツールが重いのか解っているのかな?
ついでに言えば、何と較べて重いと思っているのかな?

>>812
torrtizeSvn使ってた時はもっと軽かった

bzrが重いって言ってるのに、何でエクスプローラの話題を持ち出すのか

>>814
>813
どうやらtortoiseSVNとtortoiseBzrを較べているらしいよ。

は？

>>811
TortoiseBZRの開発者です。よかったら、バージョンとか、具体的な症状とかを
Bazaarスレかgoogle groupsのbazaar-jaに書き込んでください。
何度も更新ボタンを押さないといけないというのは、 '?' アイコンが表示されるから
最新のステータスを見るために押すのか、それとも何かの作業をした後で古い
ステータスが表示されたままなのか・・・両方かな。

個人的にはステータスが '?' のときに幾つかのメニューが表示されないのが一番の
問題と思ってるのですが、いつでも最新のステータス見たいですか？
いつでも最新の状態を見せようとすると、今の設計のままだとバックグラウンドで
動かしてるキャッシュプロセスの方が重くなってしまうから、なんとかしないとなぁ。

え？

プロファイラで分析してキャッシュプロセス高速化するしかなくね?

>>819
ファイルアクセスに時間かかってる気がする。
最適化してもたいして速くならないんじゃないかなぁ。

TortoiseBZRをエクスプローラでなくX-Finderで使うと
何もない場所で右クリックしたときのメニューがおかしい
アイコンの並び替えが、途中に混ざる

ファイルを右クリックした場合は問題ない

X-Finder側の問題？

x-finderは挙動が怪しい時があるね

ステータスチェックって、bzrの本体にやらせてるけど、多分、最新リビジョンから
取り出したファイルとディスク上のファイルを普通に比較してるんだと思う。

NTFSって、ファイルのCRCか何かをファイルの中身を読まないで取得することって
できるんだっけ？できるんだったら、それ使って独自の高速化が考えられるかも。

割切ってタイムスタンプだけ見るとか

どうでもいいけど、各論は各ツールのスレでお願いしたい。

>>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

>>826
ええっと、Twitterでつながってる人ですよね。その節はお世話になりました。
空きスロット問題は悩ましいですね。いまさらTortoiseSVN開発者に
"LockedなんていらないからUnversionedアイコン優先しろ！"とか言えない。

TortoiseBZRが提供している機能は基本的にシェル周りだけで、
コミット画面等はQBzrに丸投げしてます。
アイコンオーバーレイをオフにして、コンテキストメニューはコンテキストに依存しないで
常にフル表示するオプションがあるといい気もしますね。

>>826-827
>>825

まあ出会いがある事は良い事じゃないか
やりすぎなければね

人との出会いは大切にしたい。
と、ぼっちの俺はいつも思ってる。 ｡･ﾟ･(ﾉД`)･ﾟ･｡

異なるバージョン管理ツールの開発者が似た機能について語り合ってるのは
スレタイにふさわしいと思うぞ。

>>779
できない
他のユーザーがチェックアウト中です
ってメッセージが出て編集できない
アド民の人に複数ユーザで使えるようにチェック入れてもらうしかない

>>827
> ええっと、Twitterでつながってる人ですよね。その節はお世話になりました。

いえいえ、こちらこそPythonの参照関連のアドバイスは本当に助かりました。

> 空きスロット問題は悩ましいですね。いまさらTortoiseSVN開発者に
> "LockedなんていらないからUnversionedアイコン優先しろ！"とか言えない。

たしかに。ぶっちゃけいらないアイコンの方が多いんですよね。

> TortoiseBZRが提供している機能は基本的にシェル周りだけで、
> コミット画面等はQBzrに丸投げしてます。

あ、そうなんですか。
となるともしやるならQBzrに相談が必要ですねぇ。面倒だ。

> アイコンオーバーレイをオフにして、コンテキストメニューはコンテキストに依存しないで
> 常にフル表示するオプションがあるといい気もしますね。

その機能は是非THGにも欲しいですね。
というより、現状のTHGのコンテキストメニューはあまり賢くないんです。
コンテキストに依存しないオプションの前にもっとコンテキストに依存する方を改善すべきかもw

開発者は有意義に議論してくれ
素人は指加えてROMってるわ

Windowsでまともに使えるモノにしてからリリースしろアホ

>>835
バグレポート書かないで文句だけ言うのは建設的じゃない。
まともにつかえなかったのはhg?bzr?TortoiseHG?TortoiseBZR?
具体的な問題点は何？

えーマジWindows？　キモーイ　Windowsが許されるのは小学生までだよねー

>>836
・TortoiseGit UTF-8未対応な件。
cygwin 版git(UTF-8 DLL導入済み)において、マルチバイトファイル名を使うと正しくアイコン、ファイル名が表示されず、コミット不能。

・TortoiseHG
結局、マルチバイトファイル名使うには何がいいの？

Windowsって大変なんだな...

Windowsが大変なんじゃない、Windows対応が大変なんだ。

>>840
マルチバイト対応が大変なんだろ。
THGだって、日本語使わなきゃまともに動くし。

マルチバイトファイル名なんか使うやつはばかです

ソースの日本語コメントがdiff窓で文字化けしてて読めない
そんなwindows

Windowsにこだわるやつってなんなの? 死ぬの?

Windows対応が大変というより、最初UNIXべったりで作ったのをそれ以外に持っていくのが大変なんだと思うよ。
今はWindows以外は全部UNIXになってしまっているからWindowsが叩かれるけど、OS/2やBeOSが生き残っていたら話は違ってたと思う。

異端児Windowsｶﾜｲｿｽ

>>836
Windowsユーザは、新しいバージョンがリリースされるたびに評価し落胆し疲れ果ててるんだよ・・・

>>845
つ Haiku

>>845
＞今はWindows以外は全部UNIX
ところが、総量では逆転。ｗ

>>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

>>849
なにその中国人思考

> Windowsだけで運用するという条件付きですが、

これがダメ。もうバケバケになったログを解読するのはいやだお

また馬鹿なbzr厨が現れたのかwww
邪魔だからここに来るな

必死だな

>>852
> これがダメ。もうバケバケになったログを解読するのはいやだお

ログ？コミットログのこと？

>>855
log -v でコミットログがutf-8で、ファイル名がcp932に混ざったりしない？
ひどい例だと、古いCVSリポジトリにutf-8とeucとcp932のファイル名が
混ざってたなぁ。

>>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でも同じような状況になる気がするんですが・・・。

>気がする
>気がする
>気がする

>>857 気のせいｗ
svnとbzrはファイル名とかコミットログはunicodeで保存するから、それは平気。

svnはもうその辺数年前に通り過ぎた道

>>850
fix-utf8でなくて、win32mbcs？
win32mbcsてマルチバイドのフォルダとかファイル名大丈夫だっけか…？？
って、自分で確認しないと菜・・・

>>847
俺もういやになった
面倒だから、Tortoise系みすてて、cygwin gitでUTF-8で突っ込みまくってるｗｗｗ
git statusとかでも、ファイル名が数字のコードででてきてワロスｗ

みんなそんなに日本語のファイル名付けるん？

>>860
CygwinってUTF-8ダメなの？

>>861
UTF-8 Cygwin と、Cygwin-1.7(+LANG=ja_JP.UTF-8)ならおk。
あと、ソースにはさすがに日本語ファイル名付けないけど、
「01.詳細仕様書/テーブル定義.xls」とかはふつーにあるわ。

>>862
ファイル名にスラッシュを入れても大丈夫なの?
unixでどうなるんだろ。

>>859
> >>857 気のせいｗ
> svnとbzrはファイル名とかコミットログはunicodeで保存するから、それは平気。

ああ、もうsvnも完全にunicodeなんですか。知りませんでした。
適当なこと言ってしまってすみません。

>>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でも表示されます。

ファイル名は最悪我慢するにしても、コミットのメッセージがうっかりミスでSJISとEUC混在とかなったら死ねる
DVCSだと過去のメッセージの書き換えとかできなそうだし。

bzrもhgも、コミットログを設定されたエンコーディングでデコードしてutf-8にエンコードするね。
でも、うっかりcp932の設定のままutf-8の文字列がcp932と勘違いされてデコードされ、
デコードエラーにならずにutf-8にエンコードされて格納されてしまったことが一度だけある。
cp932こえーわ。

>>862
んじゃUTF-8 Cygwinなら、UTF-8のファイル名は化けないのかな。
UTF-8つってもMacの人が混ざると濁点がおかしくなりそうだけど…

>>866
ターミナルなら混ざってても | nkf -w とかやればそれっぽく見れるんだけどねぇ

>>863
すまん、そいつはディレクトリセパレータだ。
単に日本語ディレクトリ名 + 日本語ファイル名の例を出したかっただけなんだ。

>>868
yes. Macに関しては試したことがないからわからん。お察しの通りのような気がするけど。

ただ、ファイル名がUTF-8のときにファイルの中身がShift_JIS/CP932だと、差分を見たときなどに泣ける。(テキストのドキュメントとか)

結局、Unicodeを採用すると言いつつnormalizationで手を抜いてるんだなー。

bzr付属のdiffが色分けしてくれて便利だ
しかし、その画面のままここだけマージしてほしい、他はだめとかしてくれないのね
emacsからすればその辺便利なのかな

>>870
手を抜いているというか、手が回ってない感じだな。
svnだって対応するのに時間がかかったんだ、許してやってくれ。
https://bugs.launchpad.net/bzr/+bug/172383

>>865
fixutf8-jpでも駄目な条件を知っていれば問題ないだろ。

Eclipse環境(on Windows)でgitを試してみようかと思ってるんだけど、
msysgitとかeclipse用のgitプラグインとか、現状で完成度はどんなもんなんだろう。