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

あーそうか
ファイル名に「か゛」を使わなければ問題は起きないのか
と゛うせソースは管理しないからBazaarて゛も問題は無いのて゛すね
ファイルに日本語ファイル名を使う人は英語を読めないし
失敬失敬

>>952 「ば」

残念すぎる出来

>>944
githubの個人主体のパクリなんだろうけど、容量制限があるのかが分からない。
BTS・wikiのあるgithubからわざわざ移ってくる人はまずいないだろう

>>944
同じ終わコン同士Bazaarやれば良かったのに

>>949 >>952
OS X使うなよ。

>>957
BazaarはMacOSX以外ではNFDを扱えるのか？

>>958
LinuxとWindowsだけ使っておけよ。

>>952はNFDを勘違いしてるな。
独立した濁点と合成用の濁点は別のコードポイントが割り振られてるぞ。
問題になるのは合成用の濁点で、独立した濁点については何の問題もない。

あーそうか
ファイル名に「かU+3099」を使わなけれはU+3099問題は起きないのか
とU+3099うせソースは管理しないからBazaarてU+3099も問題は無いのてU+3099すね
ファイルに日本語ファイル名を使う人は英語を読めないし
失敬失敬

>>960は>>952を勘違いしてるな。
問題を起こさない為に日本語はこう書きましょうと言ってるんだろ。

>>857
諦めてはないよ。自分からパッチ書く気がないだけで。

> 基本バイト列で、オプションorプラグインで他文字コード対応というのがきれ
> いに実現できれば受け入れられない訳ないと思うが、

現状で問題になっているWindowsでもcygwinを使えば、かなり綺麗に文字コード対応が実現できているんだが
ここでは受け入れられているようには見えないんだよな
cygwinを入れるのは簡単なのにな

Macにもcygmacがあれば解決できるなｗ

正確には書く気がないじゃなくて、書けないだった。思わせぶりな書き方はよくない、反省

お前らマルチプラットフォームのそれこそiPhoneだろうがAndroidだろうがMac OS Xだろうが
ちゃんと日本語対応できているDropboxも参考にしろや

素人向けのバージョン管理もできるツールが対応度が高いのもどんだけ

素人向けの方がクオリティが高いのは当たり前じゃん

Dropboxにその日の成果を"日付.zip"で上げてバージョン管理

去年くらいにDropboxで一部のデータが消えたという事件があったばかりだろ

>>968
無いだろ？

>>963
パッチ書けなくても英語で議論すればいいだろ
Cygwinで困ってないなら別にいいけど

msysgitのパッチなら進展しているんですけど
http://code.google.com/p/msysgit/issues/detail?id=80

>>963
> 現状で問題になっているWindowsでもcygwinを使えば、かなり綺麗に文字コード対応が実現できているんだが
> ここでは受け入れられているようには見えないんだよな
> cygwinを入れるのは簡単なのにな

cygwinでutf-8が使えることを受け入れるとBazaarの存在意義が無くなるから

夜分遅く失礼します
MercurialのMQについて調べているのですが、この拡張の意義というのはどこにあるのでしょうか？

Mercurial MQ について - daily dayflower
http://d.hatena.ne.jp/dayflower/20090520/1242794877


上記のページを見てブランチを切ったり、コミットするまでもないような小規模な変更をするため、
というようにも受け取れたのですが、hgはsvnなどとも違って、
ブランチを切ったり切り替えたりするコストは格段に低いですよね？
何故ちょっとしたブランチを切って、そのパッチを当てたり、マージしたりといった既存の操作をすててまで、
わざわざ新しい概念や操作を持ち出してMQを使うのでしょうか？

pbranchもMQと似たような用途のようなのに、長期開発向けだったりますます意味がわかりません。

いま眠いので朝返事する

>>973
昔はrebaseとtransplant(gitのcherry-pickに相当)拡張が無かったけど、MQがあれば何でもできた。
逆に今でも、MQを使えばrebase・transplantを使わなくても同様のことはできる。

>>973
> ブランチを切ったり切り替えたりするコストは格段に低いですよね？
> 何故ちょっとしたブランチを切って、そのパッチを当てたり、マージしたりといった既存の操作をすててまで、
> わざわざ新しい概念や操作を持ち出してMQを使うのでしょうか？

gitがrebase主義の所とそうで無い所があるように、hgでもなるべく履歴をきれいにしたい、という所は多いと思う。
名前付きブランチが昔はclose出来なかったので、コストが高かった。
bookmark拡張のpull/push出来る機能も今ひとつ使い勝手が悪い。

>>973
Mercurial本体やTortoiseHgのログを眺めていると時間順に並んでいないのがあるのに気付くと思う。
これは大抵MQを使っている。

>>973
gitとの比較で、hgはローカルブランチが無いというのがある。
リビジョン・名前付きブランチ名を指定してpushすればgitのローカルブランチみたいなこともできる。
この目的にもbookmark拡張が使えるけど、普通のチェンジセットにしちゃうと、
どれが実験的・デバッグ的なチェンジセットなのか見分けがつきづらくなる。
でもMQを使っておけば、pushして良いものと、まだダメなものの見分けがつきやすい。

>>973
選択肢の問題で、

・不要なブランチを消したい
・チェンジセットをまとめたい
・別ブランチの一部のチェンジセットだけマージしたい
・ローカルではパッチをあてて作業したい（共有リポジトリ版と設定部分を変えたい）

と言うような要望が無い人には、拡張機能MQは要らない。

>>973
職場で毎日コミットするルールがあるとして、ある機能の実装に5日間かかるとする。
5回コミットされるが、5つのチェンジセットを同時にマージしないと原子性が満たされない。
また4日間分のコミット・メッセージは「#12345機能の実装途中」であり、情報としては意味が無い。
こういう時に、チェンジセットをまとめたいという要望があるのは自然だ。

>>973
　　　　　　　　　＼　　　∩─ｰ､ 　　　====
　　　　　　　　　　 ＼／　●　､_ ｀ヽ 　　======
　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　|　　 X_入__ノ 　 ミ　　　そんな餌で俺様が釣られクマ――
　　　　　　　　　　　 ､　(＿／　　　ノ　/⌒l
　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　　　　　　　　 　 〈　　　　　　　　 ＿_ノ　　====
　　　　　　　　　　　 ＼　＼＿　　　　＼
　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　　　　　　　　　＼　　 ＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　 ＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ

ありがとうございます。
歴史的な経緯があるみたいですね

まとめました

・gitでいうrebaseのような扱い >>976
・Mercurialには以前までrebaseとtransplant(gitのcherry-pickに相当)拡張が無く、MQで同様のことができた(今でもできる) >>975
・その昔、名前付きブランチはcloseできなかったのです >>976
・チェンジセットへのポインタであるgitのブランチを実現するbookmark拡張はいまいち >>976
・そもそもローカルブランチがないので、MQを使うと使い分けられる >>978
・チェンジセットをまとめるためにも使う >>980
・クマ >>981

> ブランチを切ったり切り替えたりするコストは格段に低いですよね？

というのをgitを使っていたときの感覚で言ってしまったのですが、
hgとは状況が全く違っていたようですね・・・

>> ブランチを切ったり切り替えたりするコストは格段に低いですよね？
>というのをgitを使っていたときの感覚で言ってしまったのですが、

ブランチを切る手間が問題なのではない。
Gitにもgit-resetや、git-cherry-pick、git-merge --squash、guiltがある。

>>980 職場で毎日コミットするルールがあるとして、ある機能の実装に5日間かかるとする。

これって、未完成でもコミットしなきゃいけないってことなの？
時間切れでビルドできない状態でも「毎日コミットする」ルールなんて、有害だよ？

ある機能の実装が完了してからコミットすれば良いんでは？

>>984
Subversionについて言っている？
デスクトップPCが５日目で壊れたらどうする？
いざコミットしようとしたらコンフリクトしたらどうする？
gitならmerge --squash、hgでもMQのqfoldやらいろんな手段の方が安全では無いか？

>>984
> 時間切れでビルドできない状態でも「毎日コミットする」ルールなんて、有害だよ？

Mercurialだと、ビルド不可能なチェンジセットの存在は開発の阻害にならない。つまり、
・他の人はビルドできるバージョンに戻って、コミットするだけで無名ブランチが切れる。
・SVNの2-waysマージとは違い、3-waysマージが賢いので無名ブランチのマージは怖くない。

また、編集者がローカル・リポジトリに無闇にコミットをしても、共有リポジトリへpush前に拡張機能MQでコミットの統合ができる。
つまり、コミット必須は有害なルールとも言えなくなる。

SVNでは、管理者がブランチを切りマージ性能も低いため、ビルド可能や、テスト完了済みバージョンのコミットが必須になっているだけ。

>>984
ビルドに１日かかるとしてコミットするのに１日待たないといけないの？
make clean しないでmakeだけでビルドが通るって言っているの？
Subversionの作業フォルダでmakeが通っても、他の所でmakeが通らなかったら、
コミッタが血祭りにあげられるの？

すらっと流しているけど
>他の人はビルドできるバージョンに戻って、

どうやってビルド可能なバージョンを「知る」の？
まさかいろんなバージョンをとっかえひっかえ？

管理システムの外に、もう一つ管理システムがないと実質対応できないじゃないか？

>>984
Team Foundation Serverだと、そういう場合はシェルブ機能が使えるね。
コミットはしたくないけどサーバーには上げておきたい時にシェルブを使う。

Subversionでも1.8あたりで実装予定じゃなかったっけ？

ついに、Team Foundation Serverを使った事のある奴が現れた！

>>988
フックでビルド叩くツールかませばいい
それが成功したら、Bazaarでいうメインなんたらってのにpushすればいい

機能が未完成≠コンパイルできない

なんか見えない前提がいろいろ設定されているようだ

毎日コミットするルールがある職場って人間関係が崩壊してそうだな

作業の記録として重要。進捗の確認。担当に事故があった場合にも引継ぎが楽。

それ以前に必要な会話すらできてないから毎日コミットするなんていうルールを
作っちゃうって気がする

ま、会話しても話が通じないんだけどね。

CVS/Subversionでコミット前にレビューするというルールの所は
そんな不完全な状態でレビューして何の価値があるのか聞きたい

コミットしたからって完成度が上がるわけじゃないだろう

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。