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

3年前だとSubversionは不安定というところで
2年前だとちょうどこれから普及するの確定といった感じだったかな

2年位前の状況に似てるかもしれないけど
Subversionと違って分散型はこれできまりというのがないから普及しないかも

Mercurialは使っていて楽だと思ったけど
プラットフォーム依存しちゃうのがなんとかならないのかな

WindowsでMS932、LinuxでUTF8、EUCというデフォルトエンコーディングの違いがつらい
分散だと特に各自のプラットフォームが統一されないほうが自然だし

Subversionのようにソースもリソースもドキュメントも何でもかんでもつっこむという考え方はやめたほうがいいかな

12 ：デフォルトの名無しさん：2008/07/11(金) 22:37:44

Windows NT以降はUTF-8じゃないんですか？

13 ：デフォルトの名無しさん：2008/07/11(金) 22:46:49

>>11
デフォルトエンコーディングってのは、ログメッセージのこと？
よく分からないが、Gitはそのまんま入ってるような気がする。
いっしょに使う人たちが決めればいいんじゃないのかな？

14 ：デフォルトの名無しさん：2008/07/11(金) 23:40:27

>>12
NTはOS内部では積極的にUTF16つかってたけど　表面的にはずっとSJISだよ

15 ：デフォルトの名無しさん：2008/07/12(土) 01:26:45

>>13
Windowsの入出力インタフェースは各国の糞ローカルエンコーディングに
ほぼ固定されてるようなもので、そんなに運用で融通が利くものではないよ。
UTF-8に統一とか、今更無理ですからｗ
糞デフォルトエンコーディングと内部的なワイドキャラクタセットとの
変換APIだけは完備されてるから、デフォルトエンコードを使う限り、
Windows上のツールは意識してエンコーディング設定とかしなくても
トラブル無く動くようになってることが多い。
だからそれに合わせてるSubversionみたいな態度は正しいと思う。
このあたりはMercurialの中の人も追従して欲しいものだが･･･

16 ：デフォルトの名無しさん：2008/07/12(土) 01:33:30

メモ帳で保存するとき文字コードでUTF-8を選べるから、WindowsもUTF-8で処理してるものだと
思ってたけど、違うんかいな

17 ：デフォルトの名無しさん：2008/07/12(土) 01:49:49

>>15
そういえばSubversionはロケールに合わせて変換して表示してくれるね。
みんなでUTF-8で書きましょう、てことにすればOKのような気もするが、
フロントエンドで対応するのもそう難しくはないだろうから、そのうちどうにかなるんじゃないかな。

18 ：デフォルトの名無しさん：2008/07/12(土) 02:29:49

EUC-JPとSJISとJISでもめるくらいならUTF-8統一の方がはるかにいいよな。

19 ：デフォルトの名無しさん：2008/07/12(土) 05:29:47

WindowsのUTF-16からしてサロゲートペアなしのUnicodeモドキだし

20 ：デフォルトの名無しさん：2008/07/12(土) 11:54:31

Windows NT/2000/XPはUCS2で、VistaになってUTF-16という理解だったのだが。

21 ：デフォルトの名無しさん：2008/07/12(土) 13:11:41

UCS-2 = 劣化UTF-16

22 ：デフォルトの名無しさん：2008/07/12(土) 13:42:34

サロゲートペアの扱いが違うんだっけか？

23 ：20：2008/07/12(土) 14:06:51

基本面しか存在しないからサロゲートもない、と理解してるけど。

24 ：デフォルトの名無しさん：2008/07/12(土) 16:16:37

>>11
Mercurialは今日び(ry なことが結構ある気がする

ので気に入らない・・・

25 ：デフォルトの名無しさん：2008/07/12(土) 16:35:35

>>11
> Subversionのようにソースもリソースもドキュメントも何でもかんでもつっこむという考え方はやめたほうがいいかな

何となく Word とか Excel のバイナリファイル突っ込んでもうれしくなさそうなイメージ
Mercurial は

26 ：デフォルトの名無しさん：2008/07/12(土) 20:31:54

ちゃぶ台返しをしたMacはその点成功したな

27 ：デフォルトの名無しさん：2008/07/13(日) 03:47:54

gitを勉強するために、チュートリアルをやったあと、
ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html
を読んでいるんですが、最初からわかりませんでした。

引用：
> git はファイル集合の履歴を格納するツールとして非常によく考えられたツールです。
> git は履歴を圧縮した集合として格納し、プロジェクトの内容を相互に関連した
> スナップショットとして格納します。
> git ではこれらのバージョンをコミットと呼びます。

> それらのスナップショットは必ずしもすべてが古いものから最新のものに単線で
> 並んでいるとは限りません；その代り、開発ラインが並行して進むことがあります
> (これはブランチといいます)。ブランチは分岐し統合されます。

ここで質問なんですが、Gitでいうコミットとスナップショットとは何をさすんでしょうか。
この文章からでは分かりませんでした。

28 ：デフォルトの名無しさん：2008/07/13(日) 09:17:33

>27
スナップショットはgit commitしたときに保存されるファイル・ディレクトリの内容
コミットはそれに対するポインタとコミットログとその他の付加情報をまとめたもの

29 ：デフォルトの名無しさん：2008/07/13(日) 14:42:50

>>28
ありがとうございます。
スナップショットは、changesetとは別物でしょうか。
ここで、changesetはファイルの差分の集合です(この説明であってますよね?)。

30 ：デフォルトの名無しさん：2008/07/13(日) 17:16:42

たしかGitは通常は差分では持ってないはず。
hgは差分じゃないとやだ、ってことでフォークしたんじゃなかったっけか。

31 ：デフォルトの名無しさん：2008/07/14(月) 11:11:20

hg は clone とは別にブランチが作れるけど、どんな使い道がある？
公式ドキュメントだったかでは、意味がないと言い切ってるし。

32 ：デフォルトの名無しさん：2008/07/14(月) 13:38:49

おおっと、なんとタイムリーな。
ttp://gihyo.jp/dev/feature/01/mercurial/0006
ここでちょうどブランチが出てきてるけど、ブランチとトランク(？)を
行き来するよりもう一つ独自修正用の clone 作っとけば済む話だと思うんだけどねー。
わからん。

33 ：デフォルトの名無しさん：2008/07/14(月) 14:22:46

>>31
ディスク容量を抑えられる

34 ：デフォルトの名無しさん：2008/07/14(月) 16:20:50

>>33
なるへそ。

しばらくいじってたらちょっとした発見。
小さな複数のプロジェクトをまとめて一つのリポジトリで管理する場合
clone するよりも有効かもしれない。

35 ：デフォルトの名無しさん：2008/07/14(月) 16:37:24

>>34
Gitの場合は最近はデフォでハードリンクするようになってる。

36 ：デフォルトの名無しさん：2008/07/14(月) 18:17:21

あれ、ちょうど俺が質問しにきたことが、branchそのものかもしれない。

聞きたかったのは、hgでサーバ上に中央リポジトリを用意して共同開発をする場合に
複数のバージョンを平行開発する場合は、中央リポジトリを平行開発の分だけ
用意(clone)しないといけないのかってことなんだが。

branchを使えば1つのリポジトリ内でも分岐を作れるのね。

37 ：29：2008/07/15(火) 01:46:45

>>30
ありがとうございます。
Gitは、ファイルをまるごと保存しているということでしょうか。
ということは、Gitはchangesetは保存しておらず、差分はスナップショットから計算するということでしょうか。
たしかに .git/objects 以下にそれらしいのがあるんですが、これは差分じゃなくてファイルそのままということでしょうか。

38 ：デフォルトの名無しさん：2008/07/15(火) 06:43:57

差分じゃなくて、丸ごとのメリットってなんだろうな

39 ：デフォルトの名無しさん：2008/07/15(火) 08:33:44

>>38
ロバスト、堅牢性だな。
コミットの影響範囲を小さくし、ファイルシステムが不安定だったとしてもレポジトリ全体の破綻を食い止める。

40 ：デフォルトの名無しさん：2008/07/15(火) 08:42:47

>>36
共通(基本)部分はどうやって管理するつもり？

41 ：デフォルトの名無しさん：2008/07/15(火) 09:42:45

>>37
ファイルそのまま。
ただしファイルの件が増えるとパフォーマンスの面で問題が出るらしく、
packフォーマットという形式も採用されている。これは差分というよりいくつかのコミットを
１つのファイルにまとめて圧縮しているみたい。違ってたらすまん。
詳細はこのへん。
http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/technical/pack-format.txt;hb=HEAD

42 ：デフォルトの名無しさん：2008/07/16(水) 12:34:54

Mercurial のキー認証を使ってのアクセスでコマンドを hg に限定したい場合、
SSH_ORIGINAL_COMMAND を hg で始まるか調べて実行するスクリプト
書くしかないでしょうかね。

43 ：デフォルトの名無しさん：2008/07/16(水) 13:02:02

>>42
GitでホスティングするのにGitosisってのがあるんだけど、
これPythonなので、hgにも応用はしやすい気がする。

44 ：42：2008/07/16(水) 13:15:31

なんかちょっと変でしたね。

Mercurial のキー認証を使ってのアクセスでコマンドを hg に限定したい場合、
　↓
SSHのキー認証を使ってのリモートアクセスで、コマンドを hg に限定したい場合、

ですね。

Git も Python も興味なっそんぐだなぁ…。それだったらシェルスクリプトでも書くかなあ。

45 ：デフォルトの名無しさん：2008/07/17(木) 01:35:45

>>31
ローカルリポジトリで作業中は、ちょっと修正したらガンガンコミット。
ひと段落着いて、ビルド通って、テスト通って、ドキュメントの整合取ったら、
作業開始から完了までのpatchを取る。

んで、中央リポジトリからpullして、tipをそっちに移して、patchを当てて、
まじめなコメントとともにcommit+push。
そーすると、手元でやった粒度が細かすぎるログを中央に送らずに済む。

46 ：デフォルトの名無しさん：2008/07/17(木) 02:31:18

ちょっとした修正はローカルのRCSにcommitしてる
リポジト作らなくてもいいし
ちょっと別名コピーして取っとく代わりに

47 ：43：2008/07/17(木) 03:15:39

>>44
説明が足りなかったかも知れない。
GitosisもSSH_ORIGINAL_COMMANDでSSH経由でgitコマンドしか実行できないようにする、
というやり方をしているので、参考になるかもしれない、ということです。
hgと同じPythonだしね。
まあシェルスクリプトで自作しても同じような感じにはなると思うけども。

48 ：44：2008/07/17(木) 04:26:36

>>47
いや、ちゃんとそのニュアンスで伝わっておりましたよ。
Git も Python も興味なっそんぐなんで、取ってきてまで見る気しない
ということで…。

49 ：デフォルトの名無しさん：2008/07/17(木) 11:21:13

>>42
hg専用のSSHアカウントつくってauthorized_keysのcommand=で制限すれば
いいんちゃうの？
hg-ssh使って。

50 ：デフォルトの名無しさん：2008/07/18(金) 00:42:24

>>45
hgってpushするときに送るチェンジセットを選べない（だよね？）から、ローカルで開発しているデレクトリ以外にマスタから
pullしてパッチあてて、ci+pushするだよね？

51 ：デフォルトの名無しさん：2008/07/19(土) 01:45:54

hg branchの話だろ?

52 ：デフォルトの名無しさん：2008/07/19(土) 04:35:07

問題提起(？)したものですが、>>34 が自分なりの回答かな。

たとえばファームなんかは一つのプロジェクトは小さいから、チップ単位で
カテゴリ(＝リポジトリ)とするのはそんなに不自然なことじゃないと思う。
細かい単位で別けないのは、 status 見るのが面倒になるから(Tortoise Hg 使用前提)。
そこで一つのプロジェクトで分岐したいとき、ブランチの出番じゃないかとなるわけだけど、
皆さんはどういう管理をしてるのかな。

53 ：デフォルトの名無しさん：2008/07/22(火) 09:11:00

ふっふっふ、 TortoiseHg-0.4rc3 ダウンロード一番乗り！

…と思ったら、カウント増えねーな。なんだよ。
さて、入れてみようかね。

54 ：デフォルトの名無しさん：2008/07/22(火) 11:23:23

おお、報告サンクス。俺も入れてみる。

55 ：デフォルトの名無しさん：2008/07/22(火) 18:15:54

MerculialのリポジトリのWebインターフェイスがかわっているんだけど
どうやったらできるの？

56 ：デフォルトの名無しさん：2008/07/22(火) 22:55:37

>>55
style

57 ：デフォルトの名無しさん：2008/07/24(木) 16:13:56

Mercurialのdiffって変更ファイルの逐次表示はできないのか……。
あと誰か彼等にcursesの存在を教えてやってください。Windowsじゃカラー表示できないよ。
あと5年くらいはSubversionかな……。

58 ：デフォルトの名無しさん：2008/07/25(金) 15:56:56

TortoiseHg、もうシェル拡張じゃない方がいいような気もするんだが…。
Tortoise シリーズにそれは許されないんだろうな。
まあまだ 0.4 未満だしな。

59 ：デフォルトの名無しさん：2008/07/26(土) 01:56:25

Mercurialでレポジトリを分割する上手い方法がありますか？
レポジトリが大きくなってしまったので、サブディレクトリ毎に
レポジトリを分割したいのですが。履歴も引き継ぎたい。
ぱっとググってみたけどそれらしいのは見つからず。

60 ：デフォルトの名無しさん：2008/07/28(月) 10:35:50

>>59
まだ現状では細かいプロジェクトを効率よく管理する方法はみたことないし、思いつかないねえ。
履歴を残す必要があるなら、clone して、不要なディレクトリ消していく、ぐらい？

この辺、CVS はツリーの好きなところから取ってこれるし、modules ファイルを駆使すれば
ある程度好きなように組み合わせられる。気軽に update -d ができなくなるけど。
これがあるから、なかなか CVS 捨てられないんだよね。
簡単に CVS 捨ててしまう人は modules ファイル使ってないんじゃないの？

61 ：59：2008/07/28(月) 21:23:14

>>60
やはりなさそうですか。clone&削除では不要な履歴が残って
気持ち悪そうです。
SVNから移行しようかと使い始めてみましたが、それなりに
痒い所に手が届かない所が見えてきてちょっとガッカリ。

62 ：デフォルトの名無しさん：2008/07/30(水) 12:30:12

monotoneってどうしてマイナーなの?
initial pullが遅すぎるっていう弱点はあるけど、
使い方分かりやすいし署名もできるのに。

63 ：デフォルトの名無しさん：2008/07/30(水) 16:46:41

ほいほい乗り換えるものじゃないんだから
他の物より優れてる点を挙げろ

64 ：デフォルトの名無しさん：2008/07/31(木) 00:24:36

mercurial, git, bazaarの比較はあってもmonotoneはほとんど聞かないな。

65 ：デフォルトの名無しさん：2008/07/31(木) 01:20:36

>>62
リポジトリがすぐに壊れる

66 ：デフォルトの名無しさん：2008/07/31(木) 09:21:44

>>65
それは SQLite使ってるから?
monotoneは最初のpullがとんでもなく遅いという弱点があって、
それを避けるためにpidgin はデータベースを配布してる。
そこで単一ファイルの SQLiteが便利ってことかもしれない。

67 ：デフォルトの名無しさん：2008/07/31(木) 09:55:33

リポジトリが壊れたことはないけどな
SQLiteのDBってそんなに弱かったっけ？
今は日本語のファイル名をみつけた瞬間エラーになってくれるのにちょっと困ってる

68 ：デフォルトの名無しさん：2008/07/31(木) 10:01:02

VCSの共通規格ってないものかな。
例えば、commit, checkoutあたりは名前が違っても、どんなVCSにも同じ働きのコマンドがあるだろうし、
VCSを使ったアプリケーションで共通規格を基準に作れば、企画に沿ったVCSであれば
どんなソフトでも使えて便利だと思うんだけど・・・。
もしかして、海外でだれかやってるかな？

69 ：デフォルトの名無しさん：2008/07/31(木) 10:20:40

>>68
逆にユーザインタフェースはどうでもいいから、コミットオブジェクトとマージポイントの
互換性が取れるようになって欲しいな。
git使ってるんだが、Subversionとやり取りすると疲れる…。

70 ：デフォルトの名無しさん：2008/07/31(木) 11:17:30

>>68
EmacsやEclipseは一応複数のバージョン管理システムに対して
統一的な操作を提供しようとしてる

71 ：デフォルトの名無しさん：2008/07/31(木) 21:16:12

>>68
そう言う UI 作ればいいだけなんだろうけど、そもそも複数のバージョン
管理システムを併用することってあまり無いと思うが。

72 ：デフォルトの名無しさん：2008/08/02(土) 01:47:02

>71
仕事を外部に丸投げしたら/しようとしたら、違うシステム使ってた場合とか。

73 ：デフォルトの名無しさん：2008/08/02(土) 09:43:52

どんな仕事の投げ方してるのか知らんけど、普通完成したコードなんかを
納入してもらうからバージョン管理システムなんか関係ないだろ。

逆に派遣とかで色々な職場を渡り歩くような状況だとありうるのかもしれ
ないけど、その場合バージョン管理システムなんかより開発環境の差異の
方が大きそうだし。

そもそも、バージョン管理システムで日常的に使うのは「チェックアウト」
「チェックイン」「状態表示」「差分表示」「ログ表示」ぐらいだろうから、
ちょっと使ってりゃ覚えると思うが。

74 ：デフォルトの名無しさん：2008/08/02(土) 12:28:19

>>73
うちはシステム部分だけで、デザインなんかは別の会社がやるから、
元請けのsvn介してやり取りしてるな。メールうざいし。
文言変更だとかはテスト部隊がやるし、設計関係のドキュメントも別の会社の人が
アップデートするから、中央リポジトリが無いとやってられない。
完成したコードを納品ってのは、１０年前はよくやったけど（その前に実機で試験しに
ソース持って出かけてったり）、最近はそんな悠長なシステムはやってないな。

>>71
人によってはSubversionが一番使い慣れてるとか、hgが良いとか、Gitが好きとか、
いろいろあると思うが、ようはそれらの間ですっきりマージさえできれば、
誰が何を使ってやってようが問題ないわけで、、、どうにかなって欲しいなぁ。

75 ：デフォルトの名無しさん：2008/08/02(土) 13:00:14

昔はソースを客に提出しないことが多かったな
特にプレステとかサターンの案件だと
自分の周りだけかもしれんが

76 ：デフォルトの名無しさん：2008/08/02(土) 13:43:32

>>74
それは、作業外注みたいなイメージで >>73 の派遣みたいな感じだろ。

悠長な仕事かどうかより 10年前よりお前さんの会社の立場が弱くなっ
てるだけだと思う。

77 ：デフォルトの名無しさん：2008/08/02(土) 14:52:02

>>76
システム部分しかやりたくないし、開発に専念したいから、自社で作って、
リモートでコミットして納品してるだけ。
会社の立場が弱かったら常駐させられるんじゃない？

ちなみに１０年前は別の会社だった。制御系が多かったから仕様書だけあれば
それでよかったが、今はWebやってるからどうしてもデザインと合わせないと
いけないし、クライアントからの雑多な変更も多い。

まあ会社の立場とかはどうでもいいんだけど、
ようはどれだけ他の組織とコラボしないといけないか、ということだ。
自分の周囲の人たちだけで完結するんなら、１つのバージョン管理システムを強制すれば
悩みはないだろうが、もっと自由になりたいんだよな。

78 ：77：2008/08/02(土) 15:01:03

ちなみに自社ではGitを使ってて、向こうからこっちには逐一マージしつつ、
こっちからは納品日にいっきに客先にマージするんだが、
ここのマージがけっこう苦しいことがあってね。。。
svkでどうにか凌いでるが…Subversionキツいっす…

79 ：デフォルトの名無しさん：2008/08/02(土) 18:12:11

>>78
git-svn 使えば svn との同期以外は git側で処理できるから楽なんじゃね？
何故 svk？

80 ：デフォルトの名無しさん：2008/08/02(土) 18:43:41

>>77
いや、君が現状に満足してるなら別にいいんだけど。

81 ：デフォルトの名無しさん：2008/08/02(土) 20:20:56

>>79
git-svnは使ってるけど、svn側に常にrebaseしてあげないといけないのが痛い。
公開してるGitリポジトリはrebaseできないんで（すると使ってる人全員に影響が出る）
けっきょく個々人はgit-svn、svnから先のマージはsvk使ってる。
Subversion同士でマージするのはsvk賢いよ。重いし、たまにマージうまくいかないが。。。

git-svnもsvkみたいにsvnプロパティでマージポイントの情報を残したりとか、
それかsvn1.5のmerge trackingでどうにかなったりとかするのを期待してるかんじ。

82 ：デフォルトの名無しさん：2008/08/02(土) 21:07:02

svnと同期するbranchを決めて、通常の作業はそれ以外のbranchにすれば
いいだけのような気がするが。

83 ：デフォルトの名無しさん：2008/08/02(土) 22:13:36

>>82
branchってGitのbranchのこと？　git-svnの話？

84 ：デフォルトの名無しさん：2008/08/03(日) 13:04:29

うち相手なんてバージョン管理システムの存在すら知らねえし

85 ：デフォルトの名無しさん：2008/08/03(日) 13:45:31

IBMのClearCaseは信じられんぐらいカス

86 ：デフォルトの名無しさん：2008/08/03(日) 16:55:31

「IBMの」なんていわんでくれ。あれは、IBMがお情けで拾ってあげた旧Rational社員のレゾンデートルなんだから。

87 ：デフォルトの名無しさん：2008/08/04(月) 09:25:40

SubversionみたいにMercurialも本でないかな

88 ：デフォルトの名無しさん：2008/08/04(月) 15:31:39

>>87
書籍じゃないけどこれは?
Mercurialではじめる分散構成管理
ttp://gihyo.jp/dev/feature/01/mercurial

89 ：デフォルトの名無しさん：2008/08/04(月) 16:27:59

紹介してるだけじゃん。
たまに目から鱗なコマンドがあったりするけど。
公式ドキュメントで不完全だと言い切ってるから、当分本も期待できそうにないんじゃないかな。
細かいプロジェクトをどう管理するかという話題にはこれといった回答はないし。

Mercurial は <x> できますか？
ttp://www.selenic.com/mercurial/wiki/index.cgi/JapaneseFAQ

90 ：デフォルトの名無しさん：2008/08/04(月) 19:55:33

Mercurial の時代はまだ先なのか

91 ：デフォルトの名無しさん：2008/08/04(月) 23:31:34

うちで使おうかという話が出てるんだ、ClearCase。
どうカスなのか教えてくれ。

92 ：デフォルトの名無しさん：2008/08/04(月) 23:43:51

http://hgbook.red-bean.com/

93 ：デフォルトの名無しさん：2008/08/05(火) 02:41:20

使い方でなくて管理の仕方なんだよな重要なのわ

94 ：デフォルトの名無しさん：2008/08/05(火) 03:02:58

そうだけど
アホな管理の仕方してても
後から挽回しやすいと気軽に使えるよね。
cvsの頃はディレクトリ関係でいつも気を使ってた。

95 ：デフォルトの名無しさん：2008/08/05(火) 05:31:49

>>92
もうちょっとしたら日本語訳でるかな。

96 ：デフォルトの名無しさん：2008/08/05(火) 13:12:34

CVS導入します

97 ：デフォルトの名無しさん：2008/08/05(火) 18:03:56

好きにしろ

98 ：デフォルトの名無しさん：2008/08/05(火) 22:25:35

コンビニの人じゃないのか

99 ：名無し募集中。。。：2008/08/06(水) 09:55:50

じゃあ俺はRCS

100 ：デフォルトの名無しさん：2008/08/06(水) 12:37:00

退行で対抗すればいいというものではない。

>>96
まだネタに使えるほど堕ちてはおらんぞ。

101 ：デフォルトの名無しさん：2008/08/06(水) 15:20:27

Subversionで管理しているソースコードをローカルではGitを使って細かく管理して
最後にまとめてSubversionのリポジトリにコミットという使い方をしたいんだけど
（Gitでのブランチや小刻みなコミットはSubversionのリポジトリに上げたくない）
どうしたらうまくいくんだろう
git-svnはそういう用途じゃないよね？

102 ：デフォルトの名無しさん：2008/08/06(水) 15:29:03

>>101
ローカルではRCSで細かく保存して
きりがいいところでSubversionに上げてる

103 ：デフォルトの名無しさん：2008/08/06(水) 17:32:09

>>101
まさにそういう用途のためのgit-svnなんじゃねーの？

104 ：デフォルトの名無しさん：2008/08/06(水) 21:52:06

mercurialとsvnって組み合わせでのやり方はチュートリアルにある

105 ：デフォルトの名無しさん：2008/08/06(水) 23:03:45

>>99
昔、/etcとかの設定ファイルを保存するのにRCSを使ってた。
今、同じことをするのにmercurialを使ってる。
hg clone → hg update で簡単にバックアップを取れるのが意外と便利。

106 ：105：2008/08/06(水) 23:08:49

×update
○pull

107 ：デフォルトの名無しさん：2008/08/07(木) 01:36:49

RCSは単発の設定ファイルとかで履歴とっておきたい時によく使う。
例えばwindowsのなんかのアプリの設定ファイルで
昔の設定とかメモも残しておきたいけど
コメントアウトしておくとごちゃごちゃになるとかいう時、
保険の意味でRCSで残しとく。

108 ：デフォルトの名無しさん：2008/08/07(木) 02:25:03

>>101
>>103の言うとおり、そういう用途で使ってるよ。
git-svnに雑多なコミットを上げたくない場合は、svnに送信される予定のコミット
（git-svn-idが付いていないコミット）を、git cherry-pickとかgit merge --squashとか
git resetとかで作り直せばいい。
ただし、git svn dcommitした後は、今までのブランチは捨ててdcommitしたブランチから
続きをやらないと、次にdcommitするのが難しいと思う。

109 ：デフォルトの名無しさん：2008/08/07(木) 15:22:13

異常に使い易く、軽く、頭が良く、拡張性があるバージョン管理システム Bazaar (bzr) のスレです。
Bazaar はスマートな為、例えば、プロジェクトディレクトリ下の add や commit は自動的に一括でやってくれます。

$ mkdir myproject
$ cd myproject
$ mkdir subdirectory
$ touch test1.txt test2.txt test3.txt subdirectory/test4.txt

$ bzr init
$ bzr add
added subdirectory
...
added subdirectory/test4.txt
$ bzr commit -m "Initial import"

だってよ。

Bazaarでバージョン管理【bzr>git,svn,cvs】 http://pc11.2ch.net/test/read.cgi/tech/1218083381/

110 ：デフォルトの名無しさん：2008/08/07(木) 15:24:22

Linuxで大量に設定ファイルがある場合はmercurialがいいのか

111 ：デフォルトの名無しさん：2008/08/07(木) 17:21:41

>>101
merge --squash使えばいいだろ

112 ：デフォルトの名無しさん：2008/08/07(木) 17:49:50

>>110
ルート(/)で一発 hg init カマしておけば、後は管理ディレクトリができないからよさそう。
今は CVS 使ってるんだけど、apache の一部の設定は、ディレクトリがある限り潜っていって
CVS の管理ディレクトリのファイルまで処理しようとしてエラーになることがあるんだよね。
次からは Mercurial 使おう。

113 ：デフォルトの名無しさん：2008/08/07(木) 18:13:00

bazaarって海外だと使われているみたいだけど、
国内だと全然使われてないよね？
何か問題でもあるの？

114 ：デフォルトの名無しさん：2008/08/07(木) 22:16:47

>>113
日本人は英語を読まないから
日本語の解説が豊富なほうに転ぶ。

115 ：デフォルトの名無しさん：2008/08/08(金) 10:49:40

>ttp://d.hatena.ne.jp/softether/20060202
>[質問] では、Visual SourceSafe などは使っていないのか?
>
>Visual SourceSafe は使わない。あれはビギナー (初心者) 向けのソフトだ。

>ttp://d.hatena.ne.jp/justmyfuck/20080421/1208790127
>VSSを本気で使ってるヤツらがどれくらいいるか調査する必要があると思った。
>マイクロソフトでさえも使ってないって話(team systemを使ってるんのか？)、
>上のwrite portable codeでもVSSを使ってる開発部署は悲惨すぎて同情されてた。
>何がいかんてクロスプラットフォームに対応できてないとこ、あと何かも糞タレでラベル付けも信用できん。

116 ：デフォルトの名無しさん：2008/08/08(金) 13:34:39

>>112
凄いこと思い付くな。問題も出そうだが面白そうだしパクらせてもらうよ。
ちょうど設定ファイルの管理用にRCSでもインストールしようかと思ってたところだった。

117 ： [―{}@{}@{}-] デフォルトの名無しさん：2008/08/08(金) 19:14:46

おれは
cd /usr/local/apache/conf
mkdir RCS
ci -l httpd.conf
vi httpd.conf
お手軽

118 ：デフォルトの名無しさん：2008/08/08(金) 20:44:32

× 日本人は英語を読まないから
○ 日本人は英語を読めないから

119 ：デフォルトの名無しさん：2008/08/08(金) 22:13:48

○ 日本人は英語を読まないから
○ 日本人は英語を読めないから

120 ：デフォルトの名無しさん：2008/08/09(土) 07:08:54

読まないから読めない。
子供の英語教材を聞き流しながらも一緒に聞いて(見て)いると、
結構わかるようになってきた。
真剣にやれば身につきそうな気がしないでもない。

121 ：デフォルトの名無しさん：2008/08/09(土) 08:59:01

そりゃ彼の国では子供でもできるんだから
決して難しいわけじゃないだろ
実際あちらで半年位一人で暮らしてれば否応なしに使えるようになるし

122 ：デフォルトの名無しさん：2008/08/09(土) 12:25:04

基本的に英文文献をよむ必要が無いから読まなくなったんだよね。
でも今のトラ技等の技術誌の薄さから言ってあと数年後くらいには英語文献読めないと死ねると思う。

そうなると読む方も必死なので読めるよ。（昔の蘭学者と一緒だね)

123 ：デフォルトの名無しさん：2008/08/09(土) 13:37:28

manページとかBBSならなんとか読めるんだがなぁ
チュートリアルを超えてエッセイになると、もう頭に入らなくなってくる

124 ：デフォルトの名無しさん：2008/08/09(土) 13:53:56

かなりの高等教育まで日本語オンリーでいけちゃうもんな

ってなんでこんな話してるの？

125 ：デフォルトの名無しさん：2008/08/09(土) 14:39:25

トラ技のいい加減な記事に何度もだまされた
まぁ自分が悪いんだが

126 ：デフォルトの名無しさん：2008/08/10(日) 02:43:40

質問です。
WindowsXPで使いやすいGUIを備えた分散リポジトリ型のバージョン
管理システムでお勧めなものってありますか？
商用製品でも構わないです。

127 ：デフォルトの名無しさん：2008/08/11(月) 19:51:41

>>126
Bazaar

128 ：デフォルトの名無しさん：2008/08/11(月) 21:52:56

勝手にシェル拡張をしないSubVersionのWindows用クライアントを教えてください

129 ：デフォルトの名無しさん：2008/08/11(月) 22:27:10

svn

130 ：デフォルトの名無しさん：2008/08/11(月) 22:33:12

>>128
ttp://pysvn.tigris.org/

131 ：126：2008/08/12(火) 00:38:57

>>127
ありがとうございます。検討してみます。

132 ：デフォルトの名無しさん：2008/08/12(火) 05:54:10

>>130
最近 Python 大人気だな。

133 ：デフォルトの名無しさん：2008/08/12(火) 12:09:54

Windowsでmsysgit試しています
http://code.google.com/p/msysgit/

リポジトリをつくり、適当にテキストを1行変更して git commit -a しようとすると、
You have some suspicious patch lines:

> git commit -a
*
* You have some suspicious patch lines:
*
* In 1111.txt
* trailing whitespace (line 1)
1111.txt:1:テストgemogegeg

などといわれてコミットできません。

Capi’s Corner ≫ Blog Archive ≫ Git on Windows: “You have some suspicious patch lines”
http://www.dont-panic.cc/capi/2007/07/13/git-on-windows-you-have-some-suspicious-patch-lines/

こちらのサイトで、 .git/hooks/pre-commit の
if (/\s$/) {
bad_line("trailing whitespace", $_);
}
をコメントアウトすればおｋということがわかり、実際に大丈夫だったのですが、
毎回書き換えるのが面倒です。どうにかならないでしょうか？

\Git\share\git-core\templates\hooks\pre-commit.noexec
テンプレートがかと思ったのですが、変更しても git init した後に変わりはありませんでした。

134 ：デフォルトの名無しさん：2008/08/12(火) 14:41:53

コメントにある
git-config core.autocrlf true
git-config core.safecrlf true
だと駄目なんですか？

135 ：デフォルトの名無しさん：2008/08/13(水) 07:04:30

>>59-60
TipsAndTricks - Mercurial
http://www.selenic.com/mercurial/wiki/index.cgi/TipsAndTricks#head-8f3d9818cde9d119b4f6d5ccfe592dae5b8015ad

にあるように

ConvertExtension - Mercurial
http://www.selenic.com/mercurial/wiki/index.cgi/ConvertExtension#head-dae909d38f26662194cf8888fa7d6bc649ee653f

ではダメかい？

136 ：デフォルトの名無しさん：2008/08/14(木) 00:41:01

http://www.atmarkit.co.jp/fdotnet/opensrcverman/opensrcverman02/opensrcverman02_02.html
>これは必ずビルドが通る状態のソース・コードをコミットする

Subversion使っているのが一番の問題だと思うwww

137 ：デフォルトの名無しさん：2008/08/14(木) 09:06:39

>>134
上の方にそれ使えって書いてあったね。サンクス

138 ：デフォルトの名無しさん：2008/08/14(木) 10:30:46

>>136
ハイハイ
分散型だったらそこはPUSHに読み替えようね

139 ：デフォルトの名無しさん：2008/08/14(木) 11:17:06

そう言うやつはまともに相手しても疲れるだけだよ

140 ：デフォルトの名無しさん：2008/08/14(木) 13:27:26

mercurial-1.0.2.tar.gz 13-Aug-2008 17:23

141 ：デフォルトの名無しさん：2008/08/14(木) 16:30:24

>>138
プッシュとコミットは全然別物だろwww

142 ：デフォルトの名無しさん：2008/08/14(木) 17:47:16

■■みんなでサイトつくろうぜｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ■■
「お前ら一緒にサイト作ろうぜｗｗｗｗｗｗｗｗｗｗ」
「２ちゃん越えるサイト作ろうぜｗｗｗｗ」
「仕事無いんだ･･････」
「やろうぜ！」
「みんなでサイトつくろうぜｗｗｗｗｗｗｗｗｗｗ」
http://gacco.o0o0.jp/
http://yutori.2ch.net/test/read.cgi/news4vip/1218673130/
http://ex14.vip2ch.com/test/read.cgi/part4vip/1218612197/
興味沸いたらきてください！
======================!! 人材募集中 !!======================
■プログラムを組んでくれる人
　＊サーバー側
　　言語はRubyかPerlの予定ですが、Perlが有力候補。
　　・チャット
　　　定期的にクライアントから着信があり、それに対して更新されたチャットのメッセージを返信する程度の能力。じゃなくて機能。
　　　通信するときのフォーマットは未定。
　　・ログイン・アカウント管理
　　　ログイン認証、各アカウントの点数などの管理。データベースは未定。
　　・お絵描き
　　　未定。とりあえず鯖に負担がかからない程度にたまに画像を送信してあげるって感じで
　＊クライアント側
　　はっきり言って俺もわからね。Ajaxだとかflashだとかjavaだとか。
■機能提案(正しくは人材ではなく、意見?)
　「こんな機能があったら良い!」「こうするともっと楽しくなる!」などの意見募集中。
　挨拶とか気にせずスレにどんどん書き込んでくれればおk
■デザイン
　サイトのデザインを考えてくれる人、作ってくれる人募集中。
　できればphotoshop illustrator使える人(プロジェクト共有しやすいので)

143 ：デフォルトの名無しさん：2008/08/14(木) 18:56:01

>>141
ブッシュとサミットに比べるとどう？

144 ：デフォルトの名無しさん：2008/08/17(日) 01:33:54

hgkをpythonで書き換える予定はないのかな？

145 ：デフォルトの名無しさん：2008/08/18(月) 08:53:23

亀hg 0.4 正式版が出たみたいだけど、
ログ見る限りでは rc4 からそう大きな変更はなさそう。
気が向いたら入れてみるか。

146 ：デフォルトの名無しさん：2008/08/20(水) 14:30:21

diffしたときに表示される
@@ -0,0 +1,1 @@
みたいなのってどういう意味なんですか

147 ：デフォルトの名無しさん：2008/08/20(水) 14:53:40

http://ja.wikipedia.org/wiki/Diff#.E3.83.A6.E3.83.8B.E3.83.95.E3.82.A1.E3.82.A4.E3.83.89.E5.BD.A2.E5.BC.8F_.28Unified_format.29

148 ：デフォルトの名無しさん：2008/08/20(水) 16:43:27

アリ（´▽｀）ガトウ

149 ：デフォルトの名無しさん：2008/08/22(金) 02:29:26

SCMのコマンドを使ったり、そのソースコードを参照することなく、
リポジトリのデータから、管理しているファイルの内容やログを
完全にとはいかなくても、ある程度取り出すことができるSCMはありますか？

150 ：デフォルトの名無しさん：2008/08/22(金) 03:15:47

つ[rcs]

151 ：デフォルトの名無しさん：2008/08/22(金) 08:22:52

cvsもだな。

152 ：デフォルトの名無しさん：2008/08/22(金) 16:01:09

RCSとCVSはリポジトリの内容がすべてテキストファイルで構成されてるんだっけか？

153 ：デフォルトの名無しさん：2008/08/22(金) 21:21:54

バイナリファイルのリポジトリバージョンを覗くとえらいことになっている。

154 ：デフォルトの名無しさん：2008/08/24(日) 01:06:15

暇だったので、主だったバージョン管理システムのリポジトリの形式を調べてみた
fileコマンドで調べた程度なので、大した調査はできていませんが…
間違いがあったら、指摘よろ

RCS　　　　　：テキストファイル
CVS　　　　　：テキストファイル
Subversion　：テキストファイル、形式不明のファイル(fsfs?)
Git　　　　　　：テキストファイル、形式不明のファイル
Mercurial　　：テキストファイル、"raw G3 data, byte-padded"という形式のファイル、形式不明のファイル
Bazaar　　　：テキストファイル、gzipされたテキストファイル、1つだけ形式不明のファイル
Darcs　　　　：テキストファイル、gzipされたテキストファイル

RCSとCVSは、ファイルの差分の表示形式も同じで、これらのリポジトリからファイルを復元するのは容易。
Subversion、Git、Mercurialは、独自形式のファイルに主だったデータを収めていると思われるので、
これらを解析するのに手間がかかる？Mercurialは raw G3 data 形式のファイルが展開できれば、
ある程度リポジトリの内容を理解できるかもしれない。
BazaarとDarcsは、ほとんどすべてのデータが（gzipされた）テキストファイルに収められているので、
ファイルの内容を復元しやすい。特にDarcsは全てテキストファイルがベースで、
処理速度の問題のためだろうが、コミット時のファイルがそのままの形で収められているので、
gunzipができれば各段階のファイルの復元が可能。

155 ：名無し募集中。。。：2008/08/24(日) 01:38:42

何のために調べているかわからないけど
SubversionはFSFSファイルシステム（非DB)、又はBerkeley DBを使っている

156 ：デフォルトの名無しさん：2008/08/24(日) 03:23:21

G3ってファックスが使ってる画像フォーマットの名前だな。
たまたまマジックナンバーが一致して誤判定されただけと思われる。

157 ：デフォルトの名無しさん：2008/08/24(日) 09:45:57

解析するよりもソースを見ればいいんじゃないか？

158 ：デフォルトの名無しさん：2008/08/24(日) 13:14:25

>>154
Mercurialの*.iファイルのフォーマットについては以下に書いてあったよ
ttp://www.selenic.com/mercurial/wiki/index.cgi/Revlog

159 ：デフォルトの名無しさん：2008/08/24(日) 21:48:10

TortoiseHg-0.4.1.exe

160 ：154：2008/08/24(日) 23:21:09

>>155
Subversion 1.5からはFSFSの構成も若干変わったらしい
http://www.asahi-net.or.jp/~iu9m-tcym/svndoc/svn_sharding.html

>>156
指摘サンクス
raw G3 data は誤判定のようだね

>>157
確かに
そもそもソースなしにバイナリの解析なんてほぼ不可能だな

161 ：154：2008/08/24(日) 23:27:20

>>158
資料サンクス

162 ：デフォルトの名無しさん：2008/08/24(日) 23:38:42

>>160
俺はネトゲハックでやってるぞ。
アセンブラコードを読み込んでC言語のコードを出力する逆コンパイラを自分で作って、
その出力を手動で整形して見やすくした。
それを見ながら通信プロトコルを解析してオリジナルのサーバを作った。

163 ：デフォルトの名無しさん：2008/08/25(月) 07:03:41

　　　　＿＿__
　　　／＿_.）)ﾉヽ
　　 .|ミ.l　_　 ._ i.）　　
　（＾'ﾐ/.´・ .〈・ﾘ　クローン鯖はわしが作った
　　.しi 　　r､_） |　　
　　　 |　 `ﾆﾆ' / 　　
　　　ﾉ　`ｰ―i

164 ：デフォルトの名無しさん：2008/08/25(月) 21:09:29

git-1.6.0
gitのたくさんあったコマンドがパスから消えちゃったよ。
deprecatedだったんだな、だいぶ前から。

165 ：デフォルトの名無しさん：2008/08/25(月) 22:21:30

>>154
GitはGzipじゃないか

166 ：デフォルトの名無しさん：2008/08/27(水) 05:59:03

ttp://www.moongift.jp/2008/08/msysgit/

へぇ～

167 ：デフォルトの名無しさん：2008/08/27(水) 20:24:17

>>133-134
You have some suspicious patch lines:
の同じエラーがでます。

git-config core.autocrlf true
git-config core.safecrlf true

しても、同じようなエラーがでます。（エラーがでる行数がなぜかかわっただけ）
解決する方法はないのでしょうか？

168 ：デフォルトの名無しさん：2008/08/27(水) 20:37:39

>>167 一時はうまくいきました
該当ファイル(.gitignore)の行末にスペースが入っていたためでした。
しかし、.gitignoreはよいのですが、普通のテキストで行末にスペースを入れたいときに
このままでは困ってしまいます。
結局、

.git/hooks/pre-commit の以下をコメントアウトするしかないのでしょうか？

if (/\s$/) {
bad_line("trailing whitespace", $_);
}

169 ：デフォルトの名無しさん：2008/08/27(水) 20:51:23

git について少しお聞きしたいのです。

git でファイルの削除、リネームはどうしたらよいのでしょう。

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

を読んでいるのですが、いまいちわかりません。
svn(というかTortoiseSVN)の場合、しっかりsvn側に伝えてやらないといけないのですが、
自動認識でしょうか？

170 ：169：2008/08/27(水) 21:03:18

git rm と git mv でした。基本杉すぎて吹いた。
こちらが参考になりました。

かWiki - Git/Subversionコマンド対応表
http://b4.x0.com/hiki/?Git%2FSubversion%A5%B3%A5%DE%A5%F3%A5%C9%C2%D0%B1%FE%C9%BD

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

171 ：デフォルトの名無しさん：2008/08/28(木) 01:25:38

MercurialのHTMLが適当すぎるんだけど大丈夫か？
http://selenic.com/repo/index.cgi/hg/rev/248e54a9456e

172 ：デフォルトの名無しさん：2008/08/28(木) 06:34:40

gitで日本語ファイル名を使ってみたのですが、
git status, git show, gitkなどで軒並み文字化けするのですが、こんなものでしょうか？
日本語(というかUTF-8N)でのコミットログはnkfとかlv通すとOKみたいでした。

一応、日本語ファイル名を入れたリポジトリを他ディレクトリに clone して pull しても、
きちんと日本語ファイル名が再現されるようではあるのですが・・・
「噂が怖いソフト」とかでも大丈夫なところからsjisで処理しているわけではないような気がします。

UTF-8のファイル名の環境の皆さんはどうですか？

git: 1.5.6.4 cygwin

173 ：デフォルトの名無しさん：2008/08/28(木) 15:50:54

来年から働く学生です
バージョン管理システムくらい覚えとこうと思うんですが、
いくつか種類あって、どれやろうか迷うんですが、
（会社では何使ってるか知らないので）
基本的なシステムの部分はすべて同じなのでしょうか？
同じだったらどれからでも良いかなって思うんですが

174 ：デフォルトの名無しさん：2008/08/28(木) 15:58:03

trac + svn

175 ：デフォルトの名無しさん：2008/08/28(木) 15:58:26

>>173
cvsがすべての基本
一番よく使われているのはおそらくsvn

176 ：デフォルトの名無しさん：2008/08/28(木) 16:08:50

>>173
昔から使われていればcvs
今一番多いと思われるのはsvn(cvsから移行するツールがある)
昨今はやりの分散管理方だとどれも一長一短なので会社の方針による(概念はどれも同じところを目指している）git,hg,他
ただsvn+svkは割と多いかもしれない（svkはローカル変更用にして社内のsvnに送る前に細かく手元でコミットする使い方)

まぁ、ぶっちゃけどれでもいいからログをちゃんと書いてソースの整合性をとれるならどれ使っても迷惑は掛けないと思うので自分の趣味で何か使ってみるのが好いだろう。

177 ：デフォルトの名無しさん：2008/08/28(木) 16:21:08

VSS使ってそうな予感

178 ：デフォルトの名無しさん：2008/08/28(木) 16:28:57

CVS,VSSはいくらなんでも古臭すぎ。

もし内定もらってるなら電話して社内でどんな言語やBTSを使っているか、
どんな勉強したらいいかを聞いてみたら。

179 ：デフォルトの名無しさん：2008/08/28(木) 16:39:44

えいや、と移行できなくて、まだCVS使ってるって所も
無くはないよ。

180 ：デフォルトの名無しさん：2008/08/28(木) 16:50:49

vss → svn移行ツールは有り難いんだけどえっらい苦労した

181 ：デフォルトの名無しさん：2008/08/28(木) 16:52:20

あ、それウチだ。

それと組み込み系だと大手メーカーでも存在さえ知らない場合も。
それとか、組み込み系の請負会社の人に聞いてみたら社長が無駄金だから買わないと言ったという話も聞いた。
ま、V$$を買いたいという話だったからポシャってﾖｶﾀと思うが。
まだWinCVSのんがマシ。

182 ：デフォルトの名無しさん：2008/08/28(木) 16:53:02

VSSは現役だろ

183 ：デフォルトの名無しさん：2008/08/28(木) 16:55:38

ほぼ消えつつある。

184 ：デフォルトの名無しさん：2008/08/28(木) 18:01:49

>>182
こないだロシア軍特殊部隊が使ってるのがテレビに映ったな

185 ：デフォルトの名無しさん：2008/08/28(木) 18:16:59

>>173
会社で必要なのは、変革する環境に即応出来るスキルなので、
どれから始めても大差ない。

自分に見合ったと思う、環境から始めればよい。
今の自分にとって、資料・環境が整えられやすい・かみ砕きやすい所から
始めてはいかが？

186 ：デフォルトの名無しさん：2008/08/28(木) 18:31:09

>>185
そういう事ならあえてRCSがいいんじゃないかと思ってみる。
Unixが手元にあるなら、だけどね。

リポジトリのinitとかimportとか面倒な事はとりあえず置いといて、ci, coを
何度かやってみて感覚をつかむのと、,vファイルを直に見られるのはVCSが何を
しているのか知るにはとてもいい材料だとオモ

ま、あっという間に卒業するだろうけど、その先は好きなのに移ればいいし。

187 ：デフォルトの名無しさん：2008/08/28(木) 18:37:38

>>186
自分はリポジトリに入れるまでもないファイルはローカルでRCS使ってる

188 ：デフォルトの名無しさん：2008/08/28(木) 20:09:02

> 自分に見合ったと思う、環境から始めればよい。

はじめのうちは、これがわからんのだよね。
まったく知らないんだから、自分に見合うもクソもない。

ちなみに、俺はみかままの本見て CVS から入った。
(本当は VSS なんだけど、その履歴は無かったことにしとく)
リポジトリがあって、そこからワーキングコピーを取り出して、
編集してコミットという基本はどれも大して変わらんと思うから、
シンプルな CVS は悪くないと思う。

あと、前にも書いたが、ディレクトリ管理しないことを逆手に取った(？)
modules ファイルの機能は、ほかのシステムではみたことないねぇ。
VSS にはファイル共有があるけど。

189 ：デフォルトの名無しさん：2008/08/28(木) 20:36:21

>>188
黒歴史ﾜﾛﾀ

うん、modulesに限らずcvsの柔軟性はいろんな時に助かる。
今のところ、他のVCSに移れる気はしないな。
他社プロジェクトなんかでほかのを使ったりはするけど、自分がマネージャを
やる時は全てcvsだ。

190 ：デフォルトの名無しさん：2008/08/28(木) 21:06:10

今からならMercurialだな

191 ：デフォルトの名無しさん：2008/08/28(木) 21:17:20

git と比較して Mercurial の方が良い点ってどんなところ?

192 ：デフォルトの名無しさん：2008/08/28(木) 21:22:37

今からならBazaarだろ

193 ：デフォルトの名無しさん：2008/08/28(木) 21:24:00

winならMercurial

194 ：デフォルトの名無しさん：2008/08/28(木) 23:49:08

>>191
>>30 ぐらい？

195 ：デフォルトの名無しさん：2008/08/29(金) 00:23:58

rcs知っといて損はないんじゃないの。

196 ：デフォルトの名無しさん：2008/08/29(金) 00:29:27

diffとpatchは？

197 ：173：2008/08/29(金) 05:04:34

ご回答沢山頂き、ありがとう御座いました
なんかスレ見てて略語ばっかりでびびってたんですが、
回答で出して頂いたものをググりつつ、理解が深まりました
とりあえずCVSをみてみようと思います

198 ：デフォルトの名無しさん：2008/08/29(金) 10:40:27

>>197
CVS,Subversionはみておくとして
入る会社で使ってるの聞いてみては？
ClearCase,Perforceとかは知っている範囲でも使ってるとこあるなぁ。

SunのTeamwareはMercurialに移行しつつあるんだとして
MSはVSS使ってたりするのかな？(強制デバッガ的な意味で)

いずれにせよ、集中型と分散型の2つにだいたい分類されるから
そのポリシーの違いを覚えておけば細かい違いは実務中に覚えられる。

199 ：デフォルトの名無しさん：2008/08/29(金) 10:42:07

これからは分散型でしょ。
V$$は×

200 ：デフォルトの名無しさん：2008/08/29(金) 11:25:27

>>199
VSSの強制ロック使う会社もあるからなぁ

201 ：デフォルトの名無しさん：2008/08/29(金) 11:29:55

そういう会社は終わるでしょ。

202 ：デフォルトの名無しさん：2008/08/29(金) 11:35:05

VSSはVSに統合されていたのが唯一の強みだったな。
各種アドインが出来てからそのメリットも消えたが。
プロジェクトをまたがるファイルの共有機能は便利だったな。

203 ：デフォルトの名無しさん：2008/08/29(金) 12:31:04

>>202
> VSSはVSに統合されていたのが唯一の強みだったな。

逆にそれがウザいと感じるのは俺だけではないはず。

204 ：デフォルトの名無しさん：2008/08/29(金) 12:41:07

MSも今はVSS使用は推奨すらしてないでしょ。
もう終わった物。
未だに使ってる企業はMSべったりとかじゃなく技術無い企業。

205 ：デフォルトの名無しさん：2008/08/29(金) 17:04:26

マイクロソフト自身がcvs使ってるらしいからね…

206 ：デフォルトの名無しさん：2008/08/29(金) 22:02:30

TortoiseHg 0.4.1に上がってたので試してみたが、
依然としてCommit Toolで日本語ファイル名が化けるね。
化けるの無視すれば使えるし、
それ以外では何も問題ないんだが、早く改善されないかな。

207 ：デフォルトの名無しさん：2008/08/30(土) 05:34:30

文字コードがそれぞれバラバラのファイルでも大丈夫なものなんですかこういうのって？
一応統一しておいた方がいいみたいな書かれ方してて、大丈夫なのかどうか分かるらなくって
CVSなんですけど

208 ：デフォルトの名無しさん：2008/08/30(土) 06:34:05

文字コードを統一した方がいいのはどのSCMも同じ

209 ：デフォルトの名無しさん：2008/08/30(土) 10:19:34

cvs(RCSも)はコメントが実際のファイルに埋め込まれるようなものだから、
ファイルと環境のエンコードが違うと泣きを見ることになりかねない。
Subversionはそのあたりは何とかなるけれど、同時に扱うファイルのエンコードが違うとやっぱり厄介。

210 ：デフォルトの名無しさん：2008/08/30(土) 10:55:38

VSSはSCCSベースでしょ。
"SCCS"って文字列自体が、このスレで初出なくらいだ。

211 ：デフォルトの名無しさん：2008/08/30(土) 13:44:58

UNIXでしか使えないし。

212 ：デフォルトの名無しさん：2008/08/30(土) 21:38:30

このスレいつも思うが略語多すぎでうけるｗ

213 ：デフォルトの名無しさん：2008/08/30(土) 21:39:17

キモイですね、申し訳ない

214 ：デフォルトの名無しさん：2008/08/31(日) 04:13:28

>>212
でもしょーがねーだろｗ

215 ：デフォルトの名無しさん：2008/08/31(日) 10:38:27

世の中がそうだからね

216 ：デフォルトの名無しさん：2008/08/31(日) 12:21:50

サブバとか言おうぜ、スタバみたいじゃん

217 ：デフォルトの名無しさん：2008/08/31(日) 12:56:34

コマンド名って認識であんまり略語って思ってない

218 ：デフォルトの名無しさん：2008/08/31(日) 14:47:59

日本男児たるもの全部漢字に直して語ろうぜ

219 ：デフォルトの名無しさん：2008/08/31(日) 15:39:42

副版

220 ：デフォルトの名無しさん：2008/08/31(日) 15:59:47

水野亜美

221 ：デフォルトの名無しさん：2008/08/31(日) 16:21:20

>>219
×副版
○転覆

222 ：デフォルトの名無しさん：2008/08/31(日) 16:28:04

bazaar 1.6 release

223 ：デフォルトの名無しさん：2008/09/01(月) 04:02:32

221の解説たのむ

224 ：デフォルトの名無しさん：2008/09/01(月) 04:08:15

御事割縞酢

225 ：デフォルトの名無しさん：2008/09/01(月) 04:52:04

>>223
つ[辞書]

226 ：デフォルトの名無しさん：2008/09/01(月) 05:16:31

majika!!arigato

227 ：デフォルトの名無しさん：2008/09/01(月) 15:39:45

>>165
> GitはGzipじゃないか

Git 1.5.2.5 を使ってるが
gzipが見当たらないんだが

228 ：デフォルトの名無しさん：2008/09/02(火) 19:00:41

svnからgitへのリポジトリの移行って可能なんでしょうか？
どのようにしたらよいものか・・・

操作性の移行的な解説はよく見かけるのですが

229 ：デフォルトの名無しさん：2008/09/02(火) 19:03:26

http://www.google.co.jp/

230 ：228：2008/09/02(火) 19:19:10

>>229
ありがとうございます。

wadsのblog ≫ Blog Archive ≫ [git] Subversionからgitへ移行する
http://wadslab.net/2008/07/subversion-git/

ここが参考になりました。
trunkとかtagsとかの扱いがどうなるかちょっとやってみないとわかりませんが、試行錯誤してみます。
また、わかりましたら報告します。

231 ：デフォルトの名無しさん：2008/09/03(水) 04:37:17

住民の基本はほうれんそう

232 ：デフォルトの名無しさん：2008/09/03(水) 20:07:58

いつまでもSubversion使わないで。

233 ：名無し募集中。。。：2008/09/03(水) 20:09:37

なんで? SVN最高じゃん
サーバーとネットワークで繋がっているのならば

234 ：デフォルトの名無しさん：2008/09/03(水) 20:15:00

じゃぁなにを使えばいいのさ！CVS?

235 ：デフォルトの名無しさん：2008/09/03(水) 22:56:46

つ（ここでLinusのCVS罵倒コピペ）

236 ：デフォルトの名無しさん：2008/09/03(水) 23:28:20

>>235
罵倒したのはSubversionに対してじゃなかったか?

237 ：デフォルトの名無しさん：2008/09/04(木) 00:06:08

>>236
まあ「better CVSっていう出発点から間違っている」というのは
同時にCVSに対する罵倒でもあるね。

238 ：デフォルトの名無しさん：2008/09/04(木) 09:16:35

>>236
あ、そういやそうだったｗ

239 ：デフォルトの名無しさん：2008/09/04(木) 10:23:22

何十年も(過大表現)運用された後でほざいても説得力ないねえ。
出てすぐに「(具体的にここが)これではダメだ。」とか言ってたならすごいけど。

240 ：デフォルトの名無しさん：2008/09/04(木) 10:30:26

明らかに用途に合ってないのに信者が使え使えうるさかったんじゃねーの。
で、ぃぬｓがぶちきれたと。

241 ：デフォルトの名無しさん：2008/09/05(金) 11:06:25

>>240
ありそうｗ
svn公式も「Linuxの次期VCSにsvn勧めんな用途が違う」って書いてたくらいだから、勧めちゃう人多かったんだろうな

242 ：デフォルトの名無しさん：2008/09/05(金) 12:23:30

整備が進むネット接続環境と裏腹に需要が高まる分散管理システム。
なんかジレンマのようなものを感じる。

243 ：デフォルトの名無しさん：2008/09/05(金) 13:24:31

offlineで使えるというのは、分散型SCMの副作用だろ。
本質的には、ネットワーク上のC/SモデルとP2Pモデルの違い。

244 ：デフォルトの名無しさん：2008/09/05(金) 13:26:33

いいや、ほとんどの分散型SCMはオフラインでも使えることを想定して設計されている。
だから本質の一部だ。

245 ：デフォルトの名無しさん：2008/09/05(金) 21:56:15

>>244
オフラインでも使えることを想定して設計されているのはSVKぐらいだろwww

246 ：名無し募集中。。。：2008/09/06(土) 01:48:06

SVKには3回挫折したので次はMercurialにしようと思います

247 ：デフォルトの名無しさん：2008/09/06(土) 23:27:47

で、gitとhg、どっち使えばいいのよ？

248 ：デフォルトの名無しさん：2008/09/06(土) 23:31:41

bzr

249 ：デフォルトの名無しさん：2008/09/07(日) 14:57:31

使わない

250 ：デフォルトの名無しさん：2008/09/07(日) 18:55:01

あるファイルを一から書き直したい場合、どのようにしていますか？
プログラム言語をそもそも変えて書き直すという場合もあると思うのですが、
どのようにコミットすると、他人にも分かりやすいバージョン管理になるのでしょうか？
例えば、
・そのファイルを空にしてからそのまま上書きする（空のファイルをコミットする or しない？）
・そのファイルを remove してから、新しく add し直す

251 ：デフォルトの名無しさん：2008/09/07(日) 19:04:39

＞プログラム言語をそもそも変えて書き直すという場合もあると思うのですが、
もはや別プロジェクト(別リポジトリ)だろ・・・

252 ：デフォルトの名無しさん：2008/09/07(日) 19:12:05

>>250
履歴がつながりにくくなるから一旦空にするとか新しく add するとか余計なことはやめてほしい。

253 ：デフォルトの名無しさん：2008/09/07(日) 19:55:32

>>251
PerlからPython，Rubyとかあるだろ

一旦，空にしたのをコミットして，ログにスクラッチから書き直すことを宣言するかな。

254 ：デフォルトの名無しさん：2008/09/07(日) 20:02:20

gitが使えるリポジトリホスティングサービス

・GitHub
https://github.com/
プロジェクト数無制限。100MB。無料版は公開リポジトリのみ。

・Assembla
http://www.assembla.com/
プロジェクト数無制限。200MB。svn,Mercurialにも対応。Trac,wikiつき。

・Unfuddle
http://unfuddle.com/
プロジェクト数1つ。200MB。svnにも対応。

・Rubyforge
https://rubyforge.org/
Ruby用

255 ：デフォルトの名無しさん：2008/09/08(月) 05:20:29

Mercural用のグラフビューアーってhgkしかないの？
tcl/tkをインストールしたくないんだが

256 ：デフォルトの名無しさん：2008/09/08(月) 07:34:05

つい最近svnを使い始めたのですが
バージョン管理システムにおいて文字コードが混在したり途中で換わったりした場合に起こることって
文字化けぐらいだと思ってて大丈夫ですか？
windowsとlinuxで使ってるのでうっかりすると混ざることもありそうなんで、気になっています
それ以上のなにかものすごいやばい状態を引き起こしたりするのでしょうか

257 ：デフォルトの名無しさん：2008/09/08(月) 09:26:55

darcsとTrac使えるところはないかね？

258 ：デフォルトの名無しさん：2008/09/08(月) 11:05:36

>>256
svnスレへどうぞ。文字コードはクライアントの使い方を間違わなければ大抵大丈夫。
寧ろ、改行コードがぐだぐだにならないように注意。

259 ：デフォルトの名無しさん：2008/09/08(月) 11:44:41

>>256
バージョン管理システム関係ないな。

260 ：デフォルトの名無しさん：2008/09/08(月) 12:10:03

>>257
common lisp のプロジェクト専用だけど。
http://common-lisp.net/

261 ：デフォルトの名無しさん：2008/09/08(月) 19:45:08

ちょっと暇だったので
http://hgbook.red-bean.com/
の日本語訳を下手ですが作ってみました
どなたか見て手直ししてください
↓
http://www.zshare.net/download/18391552753db6c3/

262 ：デフォルトの名無しさん：2008/09/08(月) 22:06:52

>>261
GJ!

263 ：デフォルトの名無しさん：2008/09/09(火) 02:02:03

>>261
BJ!

264 ：デフォルトの名無しさん：2008/09/09(火) 11:09:09

>>261
DJ!

265 ：デフォルトの名無しさん：2008/09/09(火) 12:25:20

>>261
JK!

266 ：デフォルトの名無しさん：2008/09/09(火) 12:25:55

>>260
さんくす。じゃあ、それのためにCL勉強すっか。
しかし、darcsの日本語Wikiひでー事になってるな。

267 ：261：2008/09/09(火) 18:56:01

すいません
古いのあげてしまいました
こちらを取ってください

http://www.zshare.net/download/18449455a21c0f3b/

268 ：デフォルトの名無しさん：2008/09/10(水) 17:50:17

すみません、質問です
↓をダウンロードしようとしたのですが、ssl証明書の有効期限が切れているようで
ウイルスが仕込まれていないか心配で怖いです。
リンク先は本物で安全でしょうか？？
http://zooko.com/darcs/darcsdir-w32-2.0.0.zip

269 ：デフォルトの名無しさん：2008/09/10(水) 18:10:57

>>268
httpsでもないのになんで証明書の期限切れとかいう話に？

270 ：デフォルトの名無しさん：2008/09/11(木) 00:13:30

>>268
外野が真贋答えてもそれ自体しんじられないと思うが？

271 ：デフォルトの名無しさん：2008/09/11(木) 00:51:28

ssl証明書でウイルスチェックもできるのか
勉強になった

272 ：デフォルトの名無しさん：2008/09/11(木) 02:55:08

>>271
サイトを成りすまして、ウィルス入りのファイルとして配布している可能性もある。
SSL証明書の有効期限切れということは実質的にサイトの安全性を保障するものが何もないということなんですよ。
おまけにダウンロード先はdarcsのwikiに載っていたものなので、誰でも書き換えられる可能性があるわけです。

273 ：デフォルトの名無しさん：2008/09/11(木) 10:19:00

>>270の言う通りだと思うぜ。

274 ：デフォルトの名無しさん：2008/09/11(木) 19:59:55

MercurialのリポジトリをGitに変換するのってできますか。あるいはその逆。

275 ：デフォルトの名無しさん：2008/09/12(金) 16:08:19

小ネタをひとつ。
Mercurial なんかで、細かく分かれたたくさんのリポジトリを一括操作するための苦肉のスクリプト。
bash 用。俺は「hgall」という名前で使ってる

#!/bin/bash

HGREPOS=".hgrepos"

if [ -z $1 ]; then
    echo "usage:"
    echo "  hgall [status|push|pull]"
    echo ""
    echo "  And set repository list to \"\$HOME/$HGREPOS\" file."
    exit 0
fi

if [ $1 != "status" ] && [ $1 != "push" ] && [ $1 != "pull" ]; then
    echo "Command is \"status\" or \"push\" or \"pull\"."
    exit 0
fi

if [ ! -e "$HOME/$HGREPOS" ]; then
    echo "$HOME/$HGREPOS not exist."
    exit 0
fi

COMMAND=$1
(つづく)

276 ：デフォルトの名無しさん：2008/09/12(金) 16:10:02

(つづき)
function checkall
{
    while read reppath; do
        if [ -z "$(echo $reppath | grep "^\s*#")" ] && [ -e $reppath ]; then
            case $COMMAND in
                "status")
                    cd $reppath
                    echo "[$reppath]"
                    hg status | grep -e ^[^\?]
                    ;;
                "push")
                    cd $reppath
                    echo "[$reppath]"
                    hg push
                    ;;
(まだつづく)

277 ：デフォルトの名無しさん：2008/09/12(金) 16:17:11

(つづき)
                "pull")
                    cd $reppath
                    echo "[$reppath]"
                    hg pull
                    ;;
            esac
        fi
    done
}

checkall < "$HOME/$HGREPOS"

(おわり)

やたら分かれて書き込んだのは、スペースを   にしたため。
見てもらったらわかると思うが、ホームディレクトリに「.hgrepos」というファイルを作ってその中に
リポジトリのパスをつらつらとフルパスで書いておく。~(ティルダ)が展開されないのはよくわからない。
コマンドは status、push、pull だけだが、なんか変な表示が出たらそのリポジトリに行って細かい操作をする。
意外と重宝している。ほかにいい方法あったら教えてちょうだい。

278 ：デフォルトの名無しさん：2008/09/12(金) 17:50:58

グーグルが女子高に侵入して撮影した事例
http://takagi-hiromitsu.jp/diary/20080911.html#p01

Service Temporarily Unavailable
若干のアクセス集中により一時的に利用できません

お使いのブラウザで「リロード（再読み込み）」操作をすれば正常に表示できる場合もあります。

お前ら・・・・

279 ：デフォルトの名無しさん：2008/09/12(金) 18:37:03

ひろみちゅタンの日記の更新直後にはよくある

280 ：デフォルトの名無しさん：2008/09/13(土) 08:56:27

278は普段ひろみちゅの日記なんてアクセスしたことないんだろうな。

281 ：デフォルトの名無しさん：2008/09/13(土) 10:46:43

あんな大してスキルもないセキュリチィ馬鹿の日記なんて、読むに値しない。
女子高侵入なんてキャッチーなキーワードであざとい宣伝、プロパガンダ。こざかしいんだよ。

282 ：デフォルトの名無しさん：2008/09/13(土) 11:46:49

>>275
なんでそれをPythonで書かないかなー

283 ：デフォルトの名無しさん：2008/09/13(土) 12:09:32

自分で書けや

284 ：デフォルトの名無しさん：2008/09/13(土) 13:03:10

monotoneで、一度つけたタグを消す方法が分かりません
（mtn tagを繰り返しても新しいタグが追加されるだけ）
どなたか教えていただけないでしょうか？

285 ：デフォルトの名無しさん：2008/09/13(土) 13:43:13

>>283
Pythonがわからないだけと正直に言えばいいのに

286 ：275-277：2008/09/13(土) 20:38:35

>>283 は俺じゃないけど、確かに Python は知らない。
ていうか、あんまりスクリプト使わないし。
手元に Perl と bash スクリプトの本があったんで、シェルである bash スクリプトにした。
Perl がよかったかな。

そもそもこんな簡単なラッパースクリプトなんか何で書いても大差あるまい。
Python で書くとなんかいいことあるのかな？

287 ：デフォルトの名無しさん：2008/09/13(土) 20:59:14

単に「MercurialがPythonで書かれているから」じゃないのか

288 ：デフォルトの名無しさん：2008/09/13(土) 21:03:47

hg extensionにして欲しかったとか。

289 ：デフォルトの名無しさん：2008/09/13(土) 21:10:51

単にレスが欲しかったんだろう

290 ：デフォルトの名無しさん：2008/09/14(日) 14:45:13

gitでリポジトリを移したいというか、サーバーを乗り換えたいときって、
git remoteのgit@hogehoge を新しいサーバーに変えて
git pushするだけでよいの？

291 ：デフォルトの名無しさん：2008/09/14(日) 15:17:49

Google Open Source Blog: Develop with Git on a Google Code Project
http://google-opensource.blogspot.com/2008/05/develop-with-git-on-google-code-project.html

292 ：デフォルトの名無しさん：2008/09/15(月) 01:56:16

規制されてたんで亀でごめん。
>>254
何も調べないで悪いが、以前見っけた。まあgithubで特に困ってないんだよなぁ。
http://gitorious.org/

>>242
今のように回線がリッチになり、マシンがパワフルになったからこそ、
分散型が可能なんじゃないの？
そういう意味ではsvnをあんまりいじめるのは可哀想な気がする。
ダイヤルアップ接続の時代に、リポジトリ丸ごと持ってこようとは思わないよな。

293 ：デフォルトの名無しさん：2008/09/15(月) 03:30:41

github使ったら1日でFreeアカウントの2%使い切ってしまったｗ
この分だと容量すぐなくなるな
gitって圧縮してあるみたいだけど、さすがにバイナリ突っ込むと膨らむね

>>254 追加
git.coderepos
http://git.coderepos.org/
CodeRepos::Share ? Trac
http://coderepos.org/share

294 ：デフォルトの名無しさん：2008/09/15(月) 06:19:49

>>292
それだったらbazaarでいいじゃない。

295 ：デフォルトの名無しさん：2008/09/16(火) 13:01:22

>>294
bazaarの特徴がいまいちわからん
よければ解説してください

296 ：デフォルトの名無しさん：2008/09/16(火) 13:34:16

google bazaar Wikipedia

297 ：デフォルトの名無しさん：2008/09/16(火) 14:10:57

>>295
http://pc11.2ch.net/test/read.cgi/tech/1218083381/

298 ：デフォルトの名無しさん：2008/09/16(火) 14:18:13

>>295
プロジェクト数無限、容量無限、プロジェクト登録しなくても自由にブランチが作れるlaunchpadが使えること。

299 ：デフォルトの名無しさん：2008/09/16(火) 16:28:03

gitで外部のdiffツール使う時はどうすればいいんでしょうか？
簡単なdiffは大概はgitkで事足りるのですが。

しかし、何故かgit diffは改行が2倍になるので使えなくて困る・・・

300 ：デフォルトの名無しさん：2008/09/17(水) 01:31:03

>>284
亀レスだがmtn db kill_tag_locally タグ名
気をつけて使えって書いてあるのでマニュアル一回は確認してから使ってな

301 ：284：2008/09/17(水) 15:20:08

ありがとう！　dbのサブコマンドだったのか・・・
これからマニュアル読み直してみます

302 ：デフォルトの名無しさん：2008/09/17(水) 15:43:36

http://www.bitbucket.org/

Github みたいな hg ホスティングサービスらしい

blog.bitbucket.org :: Big in Japan
http://blog.bitbucket.org/b/2008/09/big-in-japan/

＞According to Alexa, we’re Big in Japan. Cool!

ブログみたら日本からのトラフィックが一番って記事があってﾜﾛｽ

303 ：デフォルトの名無しさん：2008/09/19(金) 11:56:06

TortoiseHg のコミット時間などを日本時間に設定したいのですが
どこでしたらいいのですか？

304 ：デフォルトの名無しさん：2008/09/19(金) 19:15:37

>>303
リポジトリ内は必ずGMTになるのは仕方ないから
取り出すときにローカルタイムに変換するしかない。
TortoiseHgにそういうオプションがなければ、できないと思う。

305 ：デフォルトの名無しさん：2008/09/19(金) 19:47:29

windowsでユニコードファイル名に対応してるのは svn と bzr とあとなんかある？

306 ：デフォルトの名無しさん：2008/09/19(金) 22:54:31

Mercurial

307 ：デフォルトの名無しさん：2008/09/20(土) 02:07:12

Mercurialってハングルのパス扱えなかったんだけど・・・

308 ：デフォルトの名無しさん：2008/09/20(土) 03:44:30

>>307
別に問題ないでしょ。

309 ：デフォルトの名無しさん：2008/09/20(土) 03:47:31

Unicodeファイル名に対応してれば扱えるはずでしょ？
Subversionでは問題なく扱えたし。

310 ：デフォルトの名無しさん：2008/09/20(土) 08:28:56

mercurial は python3000 が出たらどうすんだろ
わざわざロケール依存にするのかな

311 ：デフォルトの名無しさん：2008/09/20(土) 09:04:51

>>307
LANGをutf8にしてないとか、設定が足りてないんでしょ。

312 ：デフォルトの名無しさん：2008/09/20(土) 09:30:05

gitはcygwin版で一応、日本語ファイル名でもコミットできたし、
バージョンもどしたり最新にしたり、クローンしたりしても日本語ファイルは生成されるようで、
大丈夫だったのですが、
コミットログの表示時とか、gitkだとどうも日本語ファイル名は化けます。
（コミットログ自体にUTF-8含めるのはOK）

こういうのってどこに文句言ったもんでしょうか？

313 ：デフォルトの名無しさん：2008/09/20(土) 09:31:39

>>312
gitの開発者もcygwinの開発者も日本語対応なんて気にしてないよ。
文句を言うんじゃなくて、自分で対応して発表したら良いよ。

314 ：デフォルトの名無しさん：2008/09/20(土) 13:09:30

gitやcygwinの問題というよりWindowsの問題だろう
Windowsを捨てるのが最善

315 ：デフォルトの名無しさん：2008/09/20(土) 13:15:11

できもしないことを

316 ：デフォルトの名無しさん：2008/09/20(土) 13:53:56

>>314
うちの周りは10割りがwindowsなので厳しいです・・・

317 ：312：2008/09/20(土) 13:55:59

>>316 名前つけわすれました。312です。

>>314
逆に聞きたいのですが、unix環境だとgitは日本語は大丈夫なのでしょうか？
linuxだとUTF-8だと思いますが・・・。

つまり、Windowsはファイル名周りはUTF-16だったと思いますが、
UTF-8へのコンバートルーチン書いてやればよいのかな・・・

318 ：デフォルトの名無しさん：2008/09/20(土) 14:07:51

cygwinのAPIはWindowsのUnicode処理関連まともにサポートしてないでしょ。
>>314は誤りで、cygwinの問題だよ。

319 ：デフォルトの名無しさん：2008/09/20(土) 14:48:11

うちの近所ではPC台数ベースでのLinux率が50%越えてるな

320 ：デフォルトの名無しさん：2008/09/20(土) 15:02:30

>>318
WindowsのUnicode処理自体に問題が
特にローカライズ関係が酷い

321 ：デフォルトの名無しさん：2008/09/20(土) 15:46:49

どのへんが？

322 ：デフォルトの名無しさん：2008/09/20(土) 17:22:08

Cygwinのロケールサポートが非常に限定的なだけ

323 ：デフォルトの名無しさん：2008/09/20(土) 18:21:02

Linuxで日本語はgitもhgも問題ない。

324 ：312：2008/09/20(土) 18:30:20

忘れてた。うちサーバーはLinuxだったw

>>318-323
みなさん。thanx!
cygwinの問題かあ・・・
パッチ書くとかでなんとかなるもんかなあ

325 ：デフォルトの名無しさん：2008/09/20(土) 18:36:08

cygwinで日本語ｗｗｗ
しかもファイル名ｗｗｗ
アリエナサス

326 ：デフォルトの名無しさん：2008/09/20(土) 20:16:02

>>324
日本人が作ってるCygwinへのパッチにUTF8サポートパッチと
マルチバイトサポートパッチがある。試してみては？
＃ロケール自体の実装もあるけどかなり古い

327 ：デフォルトの名無しさん：2008/09/20(土) 22:11:41

>>326
後者はcp932エンコーディングのバイト列扱いになるから、ローカルで使うだけならともかく、push/popは多分無理。
> ls .hg/store/data/
> ~8d~80~96~da~95~5c.txt.i
ファイル名/ディレクトリ名末尾に'\'が含まれる文字がきたときの動作もあやしい。

328 ：デフォルトの名無しさん：2008/09/20(土) 22:36:30

自分では日本語ファイル名諦めて使ってないから知らなかった。
無理なんだな残念。

329 ：デフォルトの名無しさん：2008/09/21(日) 00:18:16

日本人が作るツールで日本語ファイル名の問題なんか出たことないのに、
何で外人はその程度もできないんだ

330 ：デフォルトの名無しさん：2008/09/21(日) 00:23:04

日本人が作るツールで日本語通っても他言語通るとは限らない。

331 ：デフォルトの名無しさん：2008/09/21(日) 01:07:48

>>329
こちらにどうぞ
http://pc11.2ch.net/test/read.cgi/tech/1179424842/

332 ：デフォルトの名無しさん：2008/09/21(日) 04:11:34

>>329
ruby

333 ：デフォルトの名無しさん：2008/09/21(日) 19:01:33

svn export -r <revision> <url>
と同じことを git でやりたくて色々調べたら
git archive <revision> | tar xf -
で代用できるよという情報を得たんですが、URLはどうやって指定するんでしょうか？
--remote=<repo> というオプションがヘルプに出るので、clone などと同じかと思って
git archive --remote git://～/～.git
とかやっても無反応で、どうも上手くいっていないっぽいんですが…
cloneできるだけじゃだめで、archive用のアクセス権みたいのが必要なんでしょうか。。

334 ：デフォルトの名無しさん：2008/09/21(日) 22:32:05

言語の論理構造ベースでチェックアウトできるバージョン管理システムってありませんか？

例えば物理的に同一ファイルに定義されている
メソッドの中身だけ編集する場合はクラスをチェックアウトする必要が無い、みたいな。

335 ：デフォルトの名無しさん：2008/09/21(日) 22:38:12

>329
日本語（特にShift-JIS）が特殊過ぎるんだよ。

336 ：デフォルトの名無しさん：2008/09/21(日) 23:22:00

必要だと思えば作ればいいと思うけど、俺にはその便利さがいまいちわからんし、

> メソッドの中身だけ編集する場合はクラスをチェックアウトする必要が無い、みたいな。

>>334 がバージョン管理システムをあまり理解してないように思えるんだが。

337 ：デフォルトの名無しさん：2008/09/21(日) 23:48:39

>>336
人と編集するファイルが重なっただけでマージが必要になるのは
メンドクサイと思ったもので。
言語の文法までバージョン管理システムが把握して、必要に応じて
コミットする範囲を設定してくれたらな、と。

確かに、今存在していないということは不要ってことかもしれませんね。
参考までに、>>336さんの理解しているところのバージョン管理システムについて
教えていただけませんか？簡単にで結構です。

338 ：デフォルトの名無しさん：2008/09/21(日) 23:52:41

>>337
行が分かれてりゃ自動でマージしてくれるだろ？何が面倒なんだ？

339 ：デフォルトの名無しさん：2008/09/22(月) 00:16:55

>>337
そういうソース管理ツールもあるらしい。名前は忘れたけど。
たとえば変数名を変更したら、ほかのSCMならたんにその変数名を含む行が変更されたと認識されるだけだけど、
そいつは「変数名を変更した」ということを認識し、リポジトリにもdiffではなくてそういう情報が書き込まれるらしい。

>>337の場合なら、たとえばチェックアウトするのはファイル単位でもいいけど、
チェックインするときに、このメソッドだけ変更されている、ということを認識して
なんかよきに計らってくれるかもしれん。
今はそういうSCMがないかもしれないけど、将来的にはあっても面白いよね。

340 ：>>336：2008/09/22(月) 00:20:08

>>337
> >>336さんの理解しているところのバージョン管理システムについて
> 教えていただけませんか？簡単にで結構です。

これスレで取り上げられてるバージョン管理システムはたいてい >>338
の言うように同一ファイルを編集しても自動マージする。

もちろん同一行を編集されたりすると人手介入が必要だけど、それは
>>337 でもどうしようもないんじゃないか？

とにかく、適当なバージョン管理システムをインストールして使ってみる
ことを勧めるよ。

341 ：デフォルトの名無しさん：2008/09/22(月) 05:45:56

>>337
> 参考までに、>>336さんの理解しているところのバージョン管理システムについて
> 教えていただけませんか？簡単にで結構です。

一般的なものはどういうものか教えてくれというのならわかるが、
お前の理解を述べよとは、何様だテメエ。
人にものをたずねる態度がなってない。小学生からやりなおせ。

342 ：デフォルトの名無しさん：2008/09/22(月) 07:27:17

>>340
Subversionってファイルがぶつかった時点で'C'ってなって終了だった気がするけど、
最近は違うのかな？
初めてsvk使った時、3wayマージしてくれるのに感動したなー。

343 ：デフォルトの名無しさん：2008/09/22(月) 07:41:30

昔から使ってるけど行単位だよ。

344 ：デフォルトの名無しさん：2008/09/22(月) 10:13:55

家でやった作業 push してくるの忘れた…。orz

345 ：デフォルトの名無しさん：2008/09/22(月) 11:52:45

git rm filename
してコミットした後、これを取り消したいんだけど、どうしたらいい？
git reset HEAD^ してみたけど、git status すると deleted filename が表示されたまま。
なおまだローカルへのコミットしかしてなくて、リモートには反映してません。

346 ：デフォルトの名無しさん：2008/09/22(月) 13:37:58

>>345
git reset --hard HEAD か
git checkout filename
でどうだろ

347 ：デフォルトの名無しさん：2008/09/22(月) 16:50:04

>>344
どこでもMyMacとsshトンネルで通路を確保してある俺様

348 ：デフォルトの名無しさん：2008/09/22(月) 17:26:34

Mercurial で merge してコンフリクトが起きたとき、指定のツールを起動する前に
コンフリクトを検出した箇所に印ぐらい付けといてくれないものか…。
どこかに設定ある？

349 ：デフォルトの名無しさん：2008/09/22(月) 18:03:39

このへん？
ttp://www.selenic.com/mercurial/wiki/index.cgi/MergingManuallyInEditor

350 ：デフォルトの名無しさん：2008/09/23(火) 01:50:40

>>346
>git checkout filename

これで行けました。そうか、checkoutすればいいのか。
ありがとうございました。

351 ：348：2008/09/23(火) 03:53:27

あれ、premerge もされてないっぽいや。おかしいな、premerge=True は設定してるんだけど…。
ちなみに、TortoiseHg です。

352 ：348：2008/09/23(火) 05:08:59

うーん、今のところ kdiff3 か internal:merge ぐらいしか選択肢はないかねぇ…。

>>349 のはまだよく読んでないけど、設定ってレベルではないような…。

353 ：312：2008/09/23(火) 07:56:29

>>326
これか！やっと見つけた・・・検索しても当初上手くひっからなかったんだ。

UTF-8 Cygwin - Download
http://www.okisoft.co.jp/esc/utf8-cygwin/download.html

354 ：デフォルトの名無しさん：2008/09/24(水) 19:02:17

リビジョン管理システムで、日本語ファイル名と日本語コメントを
LinuxからEUC/UTF-8で登録してもWindowsでCP932で取り出すことができ、
WindowsからCP932で登録してもLinuxでEUC/UTF-8で取り出すことができるのは
いまのところSubversionだけでしょうか？

355 ：デフォルトの名無しさん：2008/09/24(水) 19:21:19

>>354
Mercurial

356 ：デフォルトの名無しさん：2008/09/24(水) 21:27:05

そんなにmercurial嫌いなのかよ

357 ：デフォルトの名無しさん：2008/09/24(水) 22:28:51

いまどきCVSもSubversionもVSSも使わないプロジェクトって何なの？

358 ：デフォルトの名無しさん：2008/09/24(水) 22:32:40

なに使ってるの？

359 ：デフォルトの名無しさん：2008/09/24(水) 22:46:54

「project_最新_yyyymmdd」みたいなサフィックスを付けたディレクトリが
たまっている火事場が実在するのは知っている。

360 ：デフォルトの名無しさん：2008/09/24(水) 22:51:35

>>358
マージソフトとソースコード内の修正コメントが頼り。
言うまでもないが、マージしたら毎回デグレード勃発。

361 ：デフォルトの名無しさん：2008/09/24(水) 23:08:36

そんなゴミネタはいらない

362 ：デフォルトの名無しさん：2008/09/24(水) 23:19:50

>>359
> 「project_最新_yyyymmdd」

の、"最新" がすぐ無駄になることに気付かないような奴等だから
火事場になるんじゃないか？

363 ：デフォルトの名無しさん：2008/09/24(水) 23:30:30

backup/backup20080921/backup20080920/backup/backup20080901
みたいなディレクトリ階層を見たことがある。
project_debug_20080921
project_release_20080921
project_release_20080921_debug
project_release_20080921_2
project_release_20080921-3
project_release_20080921_debug_4
project_debug_20080921-2
project_release_20080921(2)
みたいなでぃれくとり群を見たことがある。

364 ：デフォルトの名無しさん：2008/09/24(水) 23:37:38

うちのブランチとタグに酷似してる…… orz

365 ：デフォルトの名無しさん：2008/09/25(木) 00:22:12

もはやvcs使っていると考えたくもないよな、そういうのって。

366 ：デフォルトの名無しさん：2008/09/25(木) 07:46:28

リリース管理がヘボだと>>363の後者みたいになる。
vcsかどうかはあんまし関係がない。

367 ：デフォルトの名無しさん：2008/09/25(木) 07:54:18

>363の前者
要は、バックアップフォルダにバックアップフォルダごとバックアップしているってことか?
それって、バージョン管理を放棄しているな。

>363の後者
リリース版をデバッグするってこと事態あれなのに、
「リリース版のデバッグ版」としたい香具師と「あくまでデバッグ版」としたい香具師が居るわけね。
ついでに言えば、枝番の派生の仕方も三者三様?
挙句に、その枝番も「リリースの2」が二つ発生してしまっている体たらく。

368 ：デフォルトの名無しさん：2008/09/25(木) 08:27:28

つーかコミットする前にレビューぐらい通せば？

369 ：デフォルトの名無しさん：2008/09/25(木) 08:38:32

>>368
>363はVCSを使っていないって話だろ。

まぁ、そろそろスレ違いだし話を戻したいところではあるが。

370 ：デフォルトの名無しさん：2008/09/25(木) 09:30:10

mercurialでリポジトリをWebで公開したい場合、
apacheではなく、pythonのSimpleHTTPServer.pyなどとからめて公開できない？

なにかしらのAPIってないのかなぁ？
わかる方がいましたら教えてください。

371 ：デフォルトの名無しさん：2008/09/25(木) 10:58:43

>>370
よくしらんが、WSGIのようだから、どうとでもなるんじゃないの

標準のwsgiref実装を使えば自動的にBaseHTTPServerが使われることになると思うが、
apacheではなぜ嫌なの？

まあ一人で使う分にはPythonのオモチャHTTPサーバでもいいだろうけど、
本当にオモチャだぞ
デフォではforkもthreadも使わないただの反復サーバだしな
機能だのセキュリティだの性能だのを語る以前の問題

372 ：デフォルトの名無しさん：2008/09/25(木) 11:40:14

>>370
SimpleHTTPServerは無理だろ。あれはスタティックファイルだけ。
wsgirefの方を使え。
てか、なんでhg serveじゃだめなん？

373 ：デフォルトの名無しさん：2008/09/25(木) 12:09:28

>>355
横からですが、Mercurial(hg?)は日本語ファイル名、日本語コメOKなのか
TortoiseHGは日本語ダメってあったけど、コマンドライン版ならOK?

374 ：デフォルトの名無しさん：2008/09/25(木) 13:06:03

>>373
亀 Hg が日本語ダメってどこに書いてあった？
Web の情報も古くなってきてるぞ。

375 ：デフォルトの名無しさん：2008/09/25(木) 13:37:08

>>374
あれ？大丈夫になってきているのか？
確かめてみないといけんな

376 ：デフォルトの名無しさん：2008/09/25(木) 14:49:19

>>375
TortoiseHGのコミット機能以外は対応している。
コミット機能はQctを使っていてQctが対応していない。
TortoiseHG自体にもコミット機能はあるけど更新されてなくて
日本語でログを書くとおかしくなる。

377 ：デフォルトの名無しさん：2008/09/25(木) 15:06:20

>「リリース版のデバッグ版」としたい香具師と「あくまでデバッグ版」としたい香具師が居るわけね。
リリース版を品証の人がチェックするんでタグ付け必須な職場もあるです。

378 ：デフォルトの名無しさん：2008/09/25(木) 15:28:15

Release Candidate版にしとけばいいのではなかろうか

379 ：デフォルトの名無しさん：2008/09/25(木) 16:08:19

>>376
えー？俺コミットメッセージは日本語で書きまくってるけど、ログにちゃんと表示されるよ。
update ダイアログで Browse ボタンを押すと化けてるけど。
ちなみに 0.4.1。

380 ：デフォルトの名無しさん：2008/09/25(木) 20:39:17

>>363
うちの会社ではリリース版とかいう概念すらないよ
project_20080921
すべてこういう感じ。もう手遅れだと思う

381 ：デフォルトの名無しさん：2008/09/25(木) 23:18:23

>>380
手遅れと考えるより、その環境にはそういうやり方の方が合ってる
って考えた方がいいのかもしれんよ。

まあとりあえず、一人で内職してみては？
少しずつファイルサーバ漁って、初期リポジトリに投入できそうなファイルの目星をつけつつ、
自分のところで cvsなり svnなり VSS（最近だとTFSかな？）なりをコッソリ入れておいて、
使い方を試してみたり、日次バックアップとかリストアとかの運用方法を確認したりして、
来るべき日に備えておくと、近いうちに役に立つかもよ。

俺は、本番環境でデグレード障害が出た際に、「バージョン管理システムってのがあるんですが」
って言って切り出して、内職で作ってた VSSリポジトリを使ってデモやったら、いつの間にか
それが開発標準になってたよ。

382 ：デフォルトの名無しさん：2008/09/26(金) 07:22:10

TortoiseHgはコミットツールのQctが完全には日本語に
対応してなくて、コミット対象のファイル名が文字化けする。
しかし、コミット自体は日本語で正常に行われます。

383 ：デフォルトの名無しさん：2008/09/26(金) 07:23:56

TortoiseSVNもTortoiseHgもエクスプローラが重たくなる。
特にネット越しになると酷い。

384 ：デフォルトの名無しさん：2008/09/26(金) 10:35:21

>>383
アイコンオーバーレイを「固定ドライブ」だけにするといいかも。
またはアイコンオーバーレイを使わないとか。

385 ：デフォルトの名無しさん：2008/09/26(金) 10:43:01

SVNのステータスでソートしたりとか良く使うし
エクスプローラと連動してるおかげで検索から
削除したり出来るから便利ともいえるし人それぞれだろう

386 ：デフォルトの名無しさん：2008/09/26(金) 12:17:39

>>384
対象外のフォルダを検索しないとか、検索フォルダのマスクしていとかもあるよ

387 ：デフォルトの名無しさん：2008/09/27(土) 01:24:54

アイコンオーバレイ使わないと、亀使ってる意味がほとんとなくね？

388 ：デフォルトの名無しさん：2008/09/27(土) 02:14:41

シェル拡張だけでもお釣りが来ると思う

389 ：デフォルトの名無しさん：2008/09/27(土) 04:59:17

独立アプリの方がいいなあ。
特に亀 Hg は、シェル拡張の意味がほとんどないぐらい操作が複雑。
でも生き残ったのは亀なんだよねえ…。

390 ：デフォルトの名無しさん：2008/09/27(土) 06:52:09

>>389
RapidSVNは結構好きだったんだけどなぁ。
Hg用の独立アプリ無いかな。

391 ：デフォルトの名無しさん：2008/09/27(土) 06:57:25

Hgを暫く使ってて、ふとしたことから古いチェンジセットに
一時的にアップデートしたら.hg下のファイルがWindowsXPの
ファイル名256文字制限に引っかかってしまい、最新のチェンジ
セットに戻せなくなってしまったよ。
フォルダ階層深い人は注意。
しかしWinXPって256文字制限無くせないのかな。Vistaはこの点
どうなの？

392 ：デフォルトの名無しさん：2008/09/27(土) 08:18:46

NT系のパスの文字数制限はXP以前から32000文字だと思うが。
9ｘ系と互換性もたすとMAX_PATHに制限されるけど。

393 ：デフォルトの名無しさん：2008/09/27(土) 08:39:09

subst.exe で何とかならない？
Hg 使ってないから状況がよくわからんが。

394 ：デフォルトの名無しさん：2008/09/27(土) 10:30:30

subst.exeで解決できる問題なら、そもそもプロジェクトを浅いディレクトリに
配置すればいいだけの話だけど、391はプロジェクトのフォルダ階層が
異常なほど深いんじゃないの？

395 ：391：2008/09/27(土) 10:34:05

>>392-393
NTFSだけど下記のエラーメッセージでググると256文字制限があるってヒットするんだけど。
HgがMAX_PATHに制限しているのかな？
あと元々レポジトリのパスが短いのでsubst.exeでは回避できなさそう。

嵐っぽくなっちゃうけどエラーの状況：
D:\a>hg add *
adding あ\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い
\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\い\う.txt
D:\a>hg ci -m "test"
trouble committing あ/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い
/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い/い
/い/い/い/い/う.txt!
abort: ファイル名または拡張子が長すぎます。: D:\a\.hg\store\data/~82~a0/~82~a2/
~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/
~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/
~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/
~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/~82~a2/
~82~a2/~82~a4.txt.i

396 ：デフォルトの名無しさん：2008/09/27(土) 10:57:37

Hg local store creates paths too long for Windows
http://www.selenic.com/mercurial/bts/issue839

397 ：デフォルトの名無しさん：2008/09/27(土) 12:18:04

>>388
hgならともかく、SVNなら開発ツールのSCM連携機能使うだろ。

398 ：デフォルトの名無しさん：2008/09/27(土) 12:38:46

Express 版で開発してるとか、ワードの文書も SVN で管理してる
俺みたいなやつの事を忘れないでくれ。

399 ：デフォルトの名無しさん：2008/09/27(土) 13:02:33

TortoiseHgまだ、rename実装されてない？のかな
D&Dでのこぴぺ移動もまだみたいだし

400 ：デフォルトの名無しさん：2008/09/27(土) 13:45:08

まだバージョンが 0.5 もいってないからね。
俺はコマンドラインと併用。
マージツールの連携をなんとかしてほしい。

401 ：デフォルトの名無しさん：2008/09/27(土) 17:10:04

そういやツールの設定なんかがよくわからないな・・・

402 ：デフォルトの名無しさん：2008/09/27(土) 19:33:29

高速ネットワークに常時接続でブランチが自由に作成できる SVN 環境から、
分散型に乗り換える利点はどのようなものがあるでしょうか？

403 ：デフォルトの名無しさん：2008/09/27(土) 19:43:28

分散に移りたいと思ったきっかけはなに？それによるんじゃないか？

404 ：名無し募集中。。。：2008/09/27(土) 21:00:32

常時接続出来ない場所に行ったときに不便にならない

405 ：デフォルトの名無しさん：2008/09/27(土) 21:11:50

svnになれてるならsvkでも使ってみたら。
でもトロいからあんま便利とは言えないか。
速度、細かい進捗管理がしやすい。

git使い始めて結構立つのに今更、昨日始めてbisect使ってみた。
数千もパッチ管理してるとやっぱこういう手法になるのかなー。

406 ：デフォルトの名無しさん：2008/09/27(土) 21:18:00

>>353
mod_authz_svn じゃだめ?

407 ：デフォルトの名無しさん：2008/09/27(土) 21:21:29

誤爆orz

408 ：デフォルトの名無しさん：2008/09/27(土) 21:33:28

>>403 >>404

SVN に特に不満は感じていないんですけど分散型がいろいろ出ているので
何か自分が気づいていていない利点があるんじゃないかと思ったんですけど。

SVN は家か会社でしか使わないのでネットワークに接続できないことは滅多
にありません。

409 ：名無し募集中。。。：2008/09/27(土) 23:12:59

会社でもノートPCを持って無線LANの届かない現場に行く場合とか心底困るよ

410 ：デフォルトの名無しさん：2008/09/27(土) 23:15:12

Subversionに比べると、分散型はリポジトリの扱いが気楽なのが利点だと思います。

たとえばMercurialだと、
ソース書き始めた
↓
そのディレクトリの下にリポジトリ作成。チェックアウトの必要なくいきなり管理下
↓
ちょっと実験するために別ディレクトリにclone（リポジトリのコピー）
↓
修正＆コミット
↓
成功：コミットを元リポジトリにpush
失敗：cloneしたリポジトリを削除してポイ
↓
(ﾟДﾟ)ｳﾏｰ

411 ：デフォルトの名無しさん：2008/09/27(土) 23:28:50

svnからhgでブランチし放題なのとマージ覚えててくれるのはいいと思った

412 ：デフォルトの名無しさん：2008/09/27(土) 23:29:01

どこがちがうのか？

413 ：デフォルトの名無しさん：2008/09/28(日) 02:46:15

svnも1.5でマージサポート強化されてるっぽいね。
今まではブランチっつってもコピーするだけだから、マージは自分でやらないといけなかったけど、
なんかsvn1.5はプロパティにどこからマージ済みなのか記録してるっぽい。svkのマネ？

Gitの場合はコミットに一意なIDがあるから、テキトーにブランチきってもマージに悩まされずに
追いかけていける。

414 ：デフォルトの名無しさん：2008/09/28(日) 04:21:23

>>410
そうそう、分散型だとすごく気楽だよね。
個人開発でも利点があった

415 ：デフォルトの名無しさん：2008/09/28(日) 10:30:27

>>351 でも書いたけど、亀　Hg 使ってる人はマージはどうやってる？kdiff3 使ってる？
マージペインで日本語が化けるから、やや無理やりだけど WinMerge 使いたいんだよね。
でも premerge が効いてないっぽいし、バイナリファイルはどちらを採用するか聞いてこなかったり
もう設定がわけわかめ。

416 ：デフォルトの名無しさん：2008/09/28(日) 11:28:46

ブランチに試行錯誤や間違いの歴史を残すのに全然抵抗ないですけど
それでも分散型に利点はありますか？

417 ：デフォルトの名無しさん：2008/09/28(日) 11:33:46

>404

418 ：デフォルトの名無しさん：2008/09/28(日) 16:53:16

ベータ版かリリース版かというのはどのように管理してるの？

419 ：名無し募集中。。。：2008/09/28(日) 21:11:17

revisionのコメントに「>>418さんに渡した版」と書いておく程度の管理
または気持ちの問題､ｶﾅ

420 ：デフォルトの名無しさん：2008/09/29(月) 02:37:11

タグ名の最後に"-r"を付けるとか(release)

421 ：デフォルトの名無しさん：2008/09/29(月) 02:56:41

>>418
うちでは例えばバージョン名がB2.4.XからR2.4.0になる。

422 ：デフォルトの名無しさん：2008/09/29(月) 03:00:44

>>418
タグ付けてβ、それを品証がチェックしてリリース
trunk
tag
rel
のディレクトリにタグ化した日付でtagに入れてそのリリースがrelにcopyされる
品証のチェックで出たバグはtagの日付版で修正して、trunkへポートされてる
エンドユーザからのバグレポートはrelに対してになる、

423 ：デフォルトの名無しさん：2008/09/29(月) 03:42:29

>>418
tag つける。でtag名に、beta-ほげほげとか release-ほげほげとか

424 ：デフォルトの名無しさん：2008/09/29(月) 12:23:02

リポジトリをbetaフォルダからreleaseフォルダに複製してる

・・・けどタグの方がいいのか

425 ：デフォルトの名無しさん：2008/09/29(月) 12:36:21

いついつリリース版というフォルダをずっと増やしていく方針なら
タグは不要だと思うけど。

426 ：デフォルトの名無しさん：2008/09/30(火) 01:18:54

他所の cvs/svn/git リポジトリから co するときに自動的に hg 方式になって
自分で管理するときは hg でして
ci するときは cvs/svn/git 方式に自動的に変換するフィルタってない？

427 ：デフォルトの名無しさん：2008/09/30(火) 05:37:52

チェックアウト状態ではリードオンリーになっていて
編集しようとするとダイアログが開いて何のための変更か？を記述して
それをコミット時のデフォルトのコメントにしてくれるようなWindowsのツールってないですか？
TortoiseSVNの拡張機能みたいな形であれば一番いいんだけど。

428 ：デフォルトの名無しさん：2008/09/30(火) 09:48:34

それなんて VSS ？

429 ：デフォルトの名無しさん：2008/09/30(火) 10:19:30

>>427
needs-lockじゃ駄目?
lock取得するときに、やる作業をコメントに書く。
コミットするときは、最近のログメッセージから再利用。

430 ：デフォルトの名無しさん：2008/09/30(火) 16:51:34

SubversionリポジトリからMercurialに変換するツールはないんでしょうか？

431 ：デフォルトの名無しさん：2008/09/30(火) 16:51:59

gitだとsvnとの相互運用もできるっぽいのですが・・・

432 ：デフォルトの名無しさん：2008/09/30(火) 17:10:30

hg convert

433 ：デフォルトの名無しさん：2008/09/30(火) 17:35:30

>>432
Mercurial の Subversion convert extension - daily dayflower
http://d.hatena.ne.jp/dayflower/20080312/1205213450

これか・・・かなり未完成っぽいですね
hgsvn？とかいうのがよいらしいですが

434 ：デフォルトの名無しさん：2008/09/30(火) 17:42:15

hgの読み方ってハーゲーでいいの？

435 ：デフォルトの名無しさん：2008/09/30(火) 18:08:50

>>434
銀ちゃんで

436 ：デフォルトの名無しさん：2008/09/30(火) 18:38:11

水銀党で

437 ：デフォルトの名無しさん：2008/09/30(火) 18:56:57

git では
git checkout 古いコミットID
として古い状態に戻すことができます。
このあと最新状態に戻すにはどうしたらいいですか。
git checkout HEAD とか git reset --hard HEAD とかしてもだめみたいです。

438 ：デフォルトの名無しさん：2008/09/30(火) 19:07:14

>>437
HEADは現在居るブランチの先端をあらわすので、その場合のHEADは名無しブランチの先端。
つまり古いコミットIDになる。
最新の状態にしたかったら、そういうブランチをチェックアウトすればいいと思う。
git checkout master とか。

439 ：デフォルトの名無しさん：2008/09/30(火) 20:11:31

>>438
ほんとだ、名無しのブランチになってました。
git checkout master でもとに戻れました。ありがとうございます。
ただ、git checkout COMMIT_ID を実行すると、名無しのブランチができるという挙動がなんか気持ち悪い。
なんで勝手にブランチができるんだろう。。。

440 ：デフォルトの名無しさん：2008/09/30(火) 20:39:40

>>439
どこの先端でもない途中の状態を指定して取り出すんだから、名無しになるんだよ。
今居るブランチをほんとうに古い状態に戻したいなら、そのコミットを指定してresetすればいい。
そうすればそのコミットが今居るブランチの先端になる。そこより先のコミットは無くなっちゃうけどね。

441 ：デフォルトの名無しさん：2008/10/01(水) 00:28:10

俺がHEADだぁぁぁあああ！

442 ：デフォルトの名無しさん：2008/10/01(水) 00:55:10

ヘドが出るぜ!

443 ：デフォルトの名無しさん：2008/10/01(水) 12:04:21

すみませんが、せっかくの機会なので教えていただけますか。

>>440
>どこの先端でもない途中の状態を指定して取り出すんだから、名無しになるんだよ。

新しいブランチを作るのではなく、今のブランチ (main) を使ったまま、古い状態を取り出すことはできないということでしょうか。

>今居るブランチをほんとうに古い状態に戻したいなら、そのコミットを指定してresetすればいい。
>そうすればそのコミットが今居るブランチの先端になる。そこより先のコミットは無くなっちゃうけどね。

reset は、HEAD がどのコミットを表すかを変更するということでしょうか。
HEAD を変更することなく、古い状態に戻すことはできないということですか。

Git は仕組みがよくわからず、困ってます。
Mercurial はすごくわかりやすいんですけど・・・

444 ：デフォルトの名無しさん：2008/10/01(水) 16:43:32

>>443
hgは使ったことないんだが、Gitからフォークしてるので似てるはずだと思ってたんだけど、
そうでもないのか。resetとかrebase無いの？

「古い状態に戻す」が何をしたいのかよくわからないんだけど、例えば、
３つ前の状態をちょっくらワーキングコピーで見たりしたくなったんなら、
３つ前の状態をチェックアウト（git checkout HEAD~3）すればいい。
名無しブランチの先頭に居ることになるが。

今のブランチを３つ前の状態まで戻して、そこからやり直したいならリセット（git reset HEAD~3）
この場合は３つ前以降のコミットは失われる（他のブランチに残ってなければ）

＞新しいブランチを作るのではなく、今のブランチ (main) を使ったまま、古い状態を取り出すことはできないということでしょうか。

mainという名のブランチをチェックアウトしたまま古い状態を取り出す？
いま居るブランチはmain~3ですよ、みたいな感じ？　それはないな。実質そういうことになるのかも
しれないけど、main~3は他のブランチにも含まれるかもしれないし、履歴の途中を引っ張り出した場合、
そこにコミットを続けることも出来るから、それってブランチ(枝)でしょう？

git checkout HEAD~3とした時点で「名無しブランチですよ。必要なら後からgit checkout -b って
出来るよ」みたいなメッセージが出てると思う。

445 ：デフォルトの名無しさん：2008/10/01(水) 19:01:31

443ではないけど
>>444
hgの場合古い状態をワーキングコピーで見るだけならブランチにはならなくて、
古い状態からコミットしたときに初めてブランチが作られる

446 ：445：2008/10/01(水) 19:05:37

それと、hgはgitのフォークではないよな

447 ：デフォルトの名無しさん：2008/10/01(水) 19:47:23

またリポジトリ、プロジェクトホスティング見つけてきた

Project Kenai -- We're More Than Just a Forge
http://kenai.com/

SubversionとMercurialのリポジトリと、フォーラム、ML、wiki、バグトラックなど一通りのホスティングサービス

448 ：デフォルトの名無しさん：2008/10/02(木) 07:37:45

枝の古い状態みるだけなら、チェックアウトすればそれでいいじゃん?
新しいブランチは作らず名無しの状態で取り出せる。
それぞれのHEADも変更しないし、何に困ってるのか分からないんだが…

多分何がしたいのかを言った方が手っ取り早い。

449 ：デフォルトの名無しさん：2008/10/02(木) 09:26:39

>>445
> 古い状態からコミットしたときに初めてブランチが作られる

前もって hg branch でブランチを指示しないといけないんでなかった？

450 ：デフォルトの名無しさん：2008/10/02(木) 09:40:05

>>446
SDにはそんなようなこと書いてあったけどな。
でもPythonで新たに書き直してるから、フォークとは言わないかもね。

451 ：デフォルトの名無しさん：2008/10/02(木) 12:51:20

>>444
両方ともBitKeeperのコマンドを参考に作ったんじゃなかったか？

452 ：デフォルトの名無しさん：2008/10/02(木) 15:27:04

tortoiseHGの0.5出てたから入れたけど、コミットの日本語は相変わらず

一緒にbazaarも入れてみたけど
右クリックしてもbazaarのメニューが出てこないのは気のせい？

453 ：デフォルトの名無しさん：2008/10/02(木) 18:36:34

>>448
>枝の古い状態みるだけなら、チェックアウトすればそれでいいじゃん?

それだとファイルパスが違うのになるから、設定ファイルをいちいち変更しないといけない。
または現在のディレクトリを別名に変更しないといけない。

454 ：デフォルトの名無しさん：2008/10/02(木) 21:14:48

???

455 ：デフォルトの名無しさん：2008/10/03(金) 11:22:29

hg convert って最強じゃね？

456 ：デフォルトの名無しさん：2008/10/03(金) 11:38:25

>>453
フルパスが書かれたものをリポジトリに入れてるのか。

そうであってもブランチを作る必要はなくて、
チェックアウトまたはclone＋チェックアウトで済むと思うけど。

何をしたいのかがわからないから、あとはエスパーを呼んでもらうしかない。

457 ：デフォルトの名無しさん：2008/10/03(金) 12:01:04

情報を後出しばかりする上に自分の特殊な環境が特殊だと思っていないんだから
誰がどう答えてもどうにもならんでしょ

458 ：445：2008/10/03(金) 13:30:09

>>450
http://en.wikipedia.org/wiki/Mercurial_(software)
>This project started at approximately the same time as another project called Git, started by Linus Torvalds with similar aims.
>>449
名前付きのブランチをつくるならそう。名無しブランチ作るならコミットするだけ。

hgの場合
hg checkout id
で古いワーキングコピーにして、
hg checkout
で最新(tip)にできる。
hg log
はcommitやpullしない限り、何をcheckoutしていても常に同じ内容が出力される。

git少し試したけど、古いのをチェックアウトするとgit logでそれ以降のログが
見えなくなるな。

459 ：デフォルトの名無しさん：2008/10/03(金) 16:21:21

緒マラ教えて下さい。
gitのリポジトリをhgに変換する方法を

460 ：デフォルトの名無しさん：2008/10/03(金) 21:41:25

4レス前は読んだか？

$ hg help convert ~
hg convert [OPTION]... SOURCE [DEST [REVMAP]]

Convert a foreign SCM repository to a Mercurial one.

Accepted source formats:
- Mercurial
- CVS
- Darcs (legacy Darcs 1 format only)
- git
- Subversion
- Monotone
- GNU Arch

461 ：デフォルトの名無しさん：2008/10/03(金) 23:17:10

git checkout ブランチ名
としたときに、
error: You have local changes to 'README'; cannot switch branches.
といわれます。
Gitでは編集中のファイルがあるとブランチを切り替えることはできないのでしょうか。

462 ：デフォルトの名無しさん：2008/10/04(土) 00:51:03

>>460
thanx... hg convertていくつも対応してるのね

463 ：デフォルトの名無しさん：2008/10/04(土) 03:39:36

>>461
たぶんそれチェックアウト先のブランチでREADMEがぶつかってるんじゃないかな。
まっすぐ伸びてれば
M README
Switched to branch
てな感じになるはず。

464 ：デフォルトの名無しさん：2008/10/04(土) 11:15:13

で、git と mercurial のどっち使えばええの？

465 ：デフォルトの名無しさん：2008/10/04(土) 11:31:34

bazaar使えばいい。

466 ：デフォルトの名無しさん：2008/10/04(土) 13:10:06

>>464
git はわかりづらいので、mercurial のほうがいいと思う。
ただ git のほうが機能は豊富。あまり使わないけど。

467 ：デフォルトの名無しさん：2008/10/04(土) 13:35:44

>>464
流行で言えばgitでしょう。

ただ、Windowsと関わることがあるなら git はちとキツイ印象（いろいろ試したが）
そのときは Mercurialでよいかと

468 ：デフォルトの名無しさん：2008/10/04(土) 14:12:39

>>466
mercurial になくて git にある機能って具体的にナニ？

>>466
どこの流行なんでしょうか？

469 ：デフォルトの名無しさん：2008/10/04(土) 15:07:16

>>468
githubでいきなり盛り上がった印象がある。
それまでは、俺はLinux Kernel専用SCMとしか思ってなかった。

470 ：デフォルトの名無しさん：2008/10/04(土) 16:46:55

大型プロジェクトに良く使われている印象>git
linux kernel、X.org、wine、vlcなど。
hgはmozillaだけな予感。

471 ：デフォルトの名無しさん：2008/10/04(土) 17:46:54

hg も netbeans、opensolaris や xen とかで使われてる
…ってちょっとググれば分かるはずなんだがな

472 ：デフォルトの名無しさん：2008/10/04(土) 18:16:14

リポジトリ数
github(git) 30*618=18540ぐらい
launchpad(bazaar) 19002

mercurial専用ホスティング&コラボレーションサービスって無いのな。専用である必要ないって言ったらその通りだが。

473 ：デフォルトの名無しさん：2008/10/04(土) 18:25:41

>>472
bitbucket freehg projectkenai

474 ：デフォルトの名無しさん：2008/10/04(土) 18:30:29

>>473
thx.

bitbucket(mercurial) 15*40=600
他分からず。

475 ：デフォルトの名無しさん：2008/10/04(土) 18:54:37

>>468
git-svnと同等なものがHgに無い。マジで欲しい。

476 ：デフォルトの名無しさん：2008/10/04(土) 19:01:08

>>475
俺もこれほしいな

gitは、gitでGoogle Code Projectのsvnで開発なんて記事もあるくらいだからな

Google Open Source Blog: Develop with Git on a Google Code Project
http://google-opensource.blogspot.com/2008/05/develop-with-git-on-google-code-project.html

477 ：デフォルトの名無しさん：2008/10/04(土) 19:05:12

>>475-476
hgからsvnにpushする方法
http://jelmer.vernstok.nl/blog/archives/129-Pushing-Mercurial-branches-into-Subversion-using-Bazaar.html

478 ：デフォルトの名無しさん：2008/10/04(土) 19:26:00

hgsvnに含まれるhgpushsvnってのもあるらしいがバギーなようだ。hgsvnの開発も芳しくないようだし。

479 ：デフォルトの名無しさん：2008/10/04(土) 19:42:17

windows上ならbzr-svnが標準で含まれているbzrが最強な予感。
cygwin+gitならgit-svn入れるだけだろうけど。
msysgitはgit-svn入れるの難しいはず。

480 ：デフォルトの名無しさん：2008/10/04(土) 20:15:22

TorotoseHGに含まれている hg.exeで
hg mergeしようとすると、gpyfmというウインドウが立ち上がるんだけど、
これは何するものなの？
リストに何も表示されていないから、何をしたらいいかわからんｗ
acceptoとかrejectとかのボタンは表示されているが

481 ：デフォルトの名無しさん：2008/10/04(土) 21:19:29

github を使っていて、他人のプロジェクトをフォークしたんですが、
それを更新する (pull) 方法が分かりません。
つまり　someone/proj1 をフォークして myname/proj1 をつくり、
git clone git://github.com/myname/proj1
をして、自分のリポジトリに commit & push するのはいいんですが、
someone/proj1 の変更を myname/proj1 に pull する方法がわかりません。
だれか教えてください。

482 ：デフォルトの名無しさん：2008/10/05(日) 02:37:27

>>481
git remote add someone git://github.com/someone/proj1
git pull someone
かな。

483 ：デフォルトの名無しさん：2008/10/05(日) 02:38:37

>>475
http://www.bitbucket.org/durin42/hgsubversion/overview/
まだまだっぽいけど。

484 ：デフォルトの名無しさん：2008/10/05(日) 04:39:52

欲しければ実装しちゃいなよ

485 ：デフォルトの名無しさん：2008/10/05(日) 08:27:55

bazaarを介するのもhgsubversionを使うのも一抹の不安があるなぁ

486 ：デフォルトの名無しさん：2008/10/05(日) 14:11:41

Bazaarが気になったので、GCCのソースを使って計測してみた。
svn://gcc.gnu.org/svn/gcc/trunk
ソースのサイズ: 510MB

Intel(R) Atom(TM) CPU N270 @ 1.60GHz
DISK: SDHC(ext3) ＃ツッコミなしでw

使用コマンド
svn = import (svnadmin create済み)
hg = commit -A (hg init済み)
bzr = add + commit (bzr init済み)
git = add + commit (git init済み)

TAT
　　git(8m30s) > bzr(10m30s) > hg(12m40s) >> svn(60m38s)
CPUTIME
　　git(1m10s) > hg(2m55s) > bzr(5m49s) > svn(6m57s)
REPOS SIZE (ソースのサイズ除く)
　　bzr(122MB) > svn(133MB) > hg(311MB) > git(319MB)

考えていたよりbzrがいい結果。

487 ：デフォルトの名無しさん：2008/10/05(日) 17:59:01

総合的にみて hg の圧勝じゃないか

488 ：デフォルトの名無しさん：2008/10/05(日) 18:31:15

総合的にみたらgitだろ?

489 ：デフォルトの名無しさん：2008/10/05(日) 18:36:26

総合的に見るとrcsだわな。

490 ：デフォルトの名無しさん：2008/10/05(日) 18:39:23

あと10年くらいはsvnでいいや

491 ：デフォルトの名無しさん：2008/10/05(日) 18:40:21

cvsはもう勘弁

492 ：デフォルトの名無しさん：2008/10/05(日) 19:21:08

>>486
What does "TAT" mean?
"CPUTIME" is speed of command execution?

493 ：デフォルトの名無しさん：2008/10/05(日) 19:25:26

turn around timeじゃないか

494 ：デフォルトの名無しさん：2008/10/05(日) 20:54:04

>>493
その通り。

495 ：デフォルトの名無しさん：2008/10/06(月) 09:03:25

どうもです。
>>482
>git remote add someone git://github.com/someone/proj1
>git pull someone
これだと自分のローカルリポジトリのみの変更ですよね。
あとはこれをpushすれば、github上にあるリモートリポジトリにも反映されるということでしょうか。

gitは勉強中なのでわからないことがいっぱいです。

496 ：デフォルトの名無しさん：2008/10/06(月) 19:00:20

Git(ギット)勉強会メモ - kinneko@転職先募集中の日記
http://d.hatena.ne.jp/kinneko/20081004/p4

> git stash
> 日本からやってきたパッチ。最近追加。
> する直せ、今直せとボスが言う。
> 中断されると違う事やると思考の流れが止まる。続けられない。
> git stash saveとたたくと、今の状態を保管する。
> 巻き戻されて最初からボスの変更だけやって、コミットしてしまう。
> その後で、git stash applyで保管した結果を戻して作業ができる。
> tarで保管するのと違って、重なる変更点は3 way margeされる。
> ボスの変更が反映された上で、途中の作業に戻れる。

今 hg 使ってるんだが、この git stash に相当するコマンド（群）知ってる人イナイ？
コード弄ってるときにバグ発見とか、よくあるもんで…

497 ：デフォルトの名無しさん：2008/10/06(月) 19:43:01

>>496
意味がわからんし使い方もわからん
cloneすればいいんじゃねーの

498 ：デフォルトの名無しさん：2008/10/06(月) 21:03:46

>>496
http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension
これかな

499 ：デフォルトの名無しさん：2008/10/06(月) 21:22:28

>>496
> 今 hg 使ってるんだが、この git stash に相当するコマンド（群）知ってる人イナイ？
つhgext.mq

500 ：デフォルトの名無しさん：2008/10/09(木) 17:25:46

少しお聞きしたいのですが、ためしに動的なwebページをMercurialで管理しようとしています。
MySQLを使用するCMSを使っているのですが、DBのデータも管理したもんなんでしょうか？
webアプリの場合だと、DBがファイルととは別ってことは普通にあると思いますが、
みなさんはどうしてらっしゃいますか？

てか、Railsもそういった類だと思うけどバージョン管理はどうしているんだろう

501 ：デフォルトの名無しさん：2008/10/09(木) 17:29:10

うちはテーブル、ビュー、関数、ストアドプロシージャのようなスクリプトと
マスターデータをテキストとかで管理してる。

502 ：デフォルトの名無しさん：2008/10/09(木) 19:14:08

>>497-499
ありがとう
拡張になるのかー

503 ：デフォルトの名無しさん：2008/10/09(木) 21:49:34

名前ド忘れしたけど
DB専用Subversionみたいなのがあったな

504 ：デフォルトの名無しさん：2008/10/11(土) 21:52:17

[Visual Studio 2005 Team Edition for Database Professionals]
ttp://www.microsoft.com/japan/msdn/vstudio/products/vsts/dbpro/

505 ：デフォルトの名無しさん：2008/10/12(日) 15:13:25

.flaも管理したい

506 ：デフォルトの名無しさん：2008/10/13(月) 10:20:18

Subversionはバイナリの差分をとってくれますが、Mercurialはしてくれないようです。
ほかにバイナリも差分をとってくれるバージョン管理ツールはありますか。

507 ：デフォルトの名無しさん：2008/10/13(月) 14:54:48

CVS

508 ：デフォルトの名無しさん：2008/10/13(月) 15:00:52

CVS って、差分とったっけ？
バイナリは、そのまま保存しかできないと思っていたけど。

509 ：デフォルトの名無しさん：2008/10/13(月) 16:15:45

>>506
Mercurialも差分を取るだろ

510 ：デフォルトの名無しさん：2008/10/13(月) 16:32:24

>>506
軽く試した感じだとちゃんと差分で保持してるよ。

511 ：デフォルトの名無しさん：2008/10/13(月) 18:22:37

git は?

512 ：デフォルトの名無しさん：2008/10/13(月) 18:23:27

ってそもそも差分じゃないか。スマン。

513 ：デフォルトの名無しさん：2008/10/13(月) 18:42:48

Mercurial を使って自分のコードを管理していたのですが、
Mercurial のリポジトリをホストしてくれる Bitbucket に移行しようとしています。
しかし新しく自分用のリポジトリを登録したのはいいんですが、
ローカルにあるリポジトリをサーバに移動する方法がよくわかりません。
もしご存知の方がいましたら教えてください。

514 ：デフォルトの名無しさん：2008/10/13(月) 19:34:24

>>508
一応無理やり差分は取ってる。あんまり効率的ではないだろうけど(昔の実験結果より)。

515 ：デフォルトの名無しさん：2008/10/13(月) 20:19:43

>>513
hg push https://[email protected]/hoge/repo
めんどくさかったら .hg/hgrc に書いとけ、な。

516 ：デフォルトの名無しさん：2008/10/14(火) 13:15:59

>>35 mercurialもclone直後はハードリンクになっているけど
変更をcommitすると別物になるようだ。

517 ：デフォルトの名無しさん：2008/10/14(火) 15:03:34

gitはテキストとバイナリの区別をしないで
オブジェクトデータベース内のすべてのオブジェクトについて
「似ているもの同士は差分で保持」という実装

518 ：デフォルトの名無しさん：2008/10/14(火) 19:08:06

いいね、バックアップソリューションでもそういうのが流行ってるみたいだし。

519 ：デフォルトの名無しさん：2008/10/14(火) 20:20:24

>>517
へー、そうなんだ。
「似ているもの同士」ってどうやって判断してるの?
その辺について書かれたドキュメントとか知ってたら教えてもらえると嬉しい。

520 ：デフォルトの名無しさん：2008/10/14(火) 21:21:12

ソース嫁よ

521 ：デフォルトの名無しさん：2008/10/14(火) 21:50:51

>>517
これほんと?
Gitって、差分は管理してなくて、すべてのファイルを圧縮保存していると資料に書いてあったけど。

522 ：デフォルトの名無しさん：2008/10/14(火) 21:54:31

Git と Mercurial の連携・・・・ってできますか？
いや意味があるのかといわれるとそれまでなんですけど。

523 ：デフォルトの名無しさん：2008/10/14(火) 22:03:04

cvsってdiffでバイナリ差分とってる訳？

524 ：デフォルトの名無しさん：2008/10/15(水) 03:37:07

>>517 「似ている」ってどうやって判別してんだ？

525 ：デフォルトの名無しさん：2008/10/15(水) 03:40:21

CVS は「バイナリ」じゃなくて「キーワード・行末変換なし」っていう設定で diff はいちおう
通してたような記憶があるお。 0x0a が現れるといちおう区切られるっていう

526 ：デフォルトの名無しさん：2008/10/15(水) 17:41:15

git pull して git push するのに疲れました。
２つを連続してやってくれるコマンドオプションとかありますか。

527 ：デフォルトの名無しさん：2008/10/15(水) 17:44:00

bat

528 ：デフォルトの名無しさん：2008/10/15(水) 17:58:15

sh & alias

529 ：デフォルトの名無しさん：2008/10/15(水) 23:53:17

>>527,528
そんなオプションはないということですね。
これで安心してshellスクリプトを書けます。
ありがとうございました。

530 ：デフォルトの名無しさん：2008/10/16(木) 22:25:14

aliasでいいじゃん

531 ：デフォルトの名無しさん：2008/10/18(土) 23:40:14

>>503
「DBAを救え! DBリファクタリングツール「LiquiBase」を使ってみよう」
http://journal.mycom.co.jp/articles/2007/10/25/liquibase/index.html

これのことかな？

532 ：デフォルトの名無しさん：2008/10/19(日) 01:42:03

>>531
それそれ！

533 ：デフォルトの名無しさん：2008/10/19(日) 04:00:46

>>500
データってデータそのもの? スキーマだけじゃなく?
SQLite にしてデータベースファイル突っ込んどけば?

Rails だとマイグレーションという仕組みでスキーマを版管理する。
テスト用のデータについてはフィクスチャで流し込むのが一般的。
実運用のデータをバージョン管理するという話はあまり聞かないな。

534 ：デフォルトの名無しさん：2008/10/19(日) 23:30:08

git push origin master
と同じことを Mercurial でするにはどうしたらいいですか。
ローカルのリポジトリを、リモートに移動しようとしています。

535 ：デフォルトの名無しさん：2008/10/19(日) 23:39:58

clone すればいいんじゃね？

536 ：デフォルトの名無しさん：2008/10/20(月) 23:25:07

>>534
gitのことはよくわからんけど、ローカルのチェンジセットをリモートに push するだけなら
hg push <remote-addr>
ローカルとリモートのリポジトリが同一のツリーでないなら
hg push -f <remote-addr>

537 ：デフォルトの名無しさん：2008/10/21(火) 01:25:59

>>534
git -> hg

538 ：デフォルトの名無しさん：2008/10/21(火) 07:22:29

Subversionスレでも出ていた話題ですが、
http://pc11.2ch.net/test/read.cgi/tech/1215565366/489-502
Mercurial(hg)て file:// でも排他処理されてますか？
多人数で共有ファイル鯖の上にpushしても大丈夫？

どこかドキュメントに記述はありますでしょうか？

539 ：デフォルトの名無しさん：2008/10/21(火) 08:10:28

>>538
問題ない

Distributed revision control with Mercurialに書いてある。

540 ：デフォルトの名無しさん：2008/10/21(火) 09:11:04

>>539
ありがとう

どの辺の章に書いてありましたか？以下で「排他」「file://」あたりで検索したのですが、
見つけられませんでした

Distributed revision control with Mercurial
http://ursm.jp/hgbook/hgbook.html

541 ：デフォルトの名無しさん：2008/10/21(火) 09:58:55

>>540
4.5.3 並行アクセス

542 ：デフォルトの名無しさん：2008/10/21(火) 15:53:31

>>541
Thanks!! 見つけられました。安心したっす

4 Behind the scenes
http://ursm.jp/hgbook/hgbookch4.html#x8-810004.5

543 ：デフォルトの名無しさん：2008/10/25(土) 14:06:51

hg convert がうごかないんだが、なんでかな?
% hg convert -s svn svn://svn.freebsd.org/base
assuming destination base-hg
initializing destination base-hg repository
Subversion python bindings could not be loaded
abort: svn://svn.freebsd.org/base: unknown repository type

% hg convert -s svn freebsd-head
assuming destination freebsd-head-hg
initializing destination freebsd-head-hg repository
Subversion python bindings could not be loaded
abort: freebsd-head: unknown repository type

544 ：デフォルトの名無しさん：2008/10/25(土) 14:57:01

>>543
Subversion python bindings could not be loaded

545 ：デフォルトの名無しさん：2008/10/25(土) 23:48:26

開発やってる奴でその質問はどうなんだ(´・ω・｀)

546 ：デフォルトの名無しさん：2008/10/26(日) 00:27:27

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

547 ：デフォルトの名無しさん：2008/10/26(日) 01:55:24

>>546
エラーメッセージ完全スルーで2ch丸投げとか、
流石に情けないんじゃないのか、って話だと思うんだが。

548 ：デフォルトの名無しさん：2008/10/26(日) 17:11:14

んなこと全員分かってるわ

549 ：543：2008/10/26(日) 21:23:22

みなさんぼろくそいってくれてありががとう
devel/py-subversionをインストールしたら動き出しました。
エラーメッセージは読み違えていて
convert/subversion.pyが見つからないのかとおもってました。
ktraceしても原因は見つけられず。
どこかにconvert subversionはプロセスを起動するとあったので
てっきりsvnをforkexecするものだと...

550 ：デフォルトの名無しさん：2008/10/26(日) 23:11:53

おまい、おもろい。ｗ

551 ：デフォルトの名無しさん：2008/10/27(月) 06:54:35

TortoiseHgのリポジトリがBitbucketに移動してた

552 ：デフォルトの名無しさん：2008/10/27(月) 10:59:33

Python 2.5 の公式ドキュメント日本語訳完成
ttp://www.python.jp/doc/

553 ：デフォルトの名無しさん：2008/10/27(月) 21:53:54

hgでパーミッションが保存されないんですが仕様ですか?
% hg init a
% cd a
% date>file
% date>file2
% chmod a-w file2
% ls -al
total 8
drwxr-xr-x 3 hoge hoge 5 10 27 21:44 ./
drwxr-xr-x 7 hoge hoge 9 10 27 21:43 ../
drwxr-xr-x 3 hoge hoge 5 10 27 21:43 .hg/
-rw-r--r-- 1 hoge hoge 40 10 27 21:43 file
-r--r--r-- 1 hoge hoge 40 10 27 21:44 file2
% hg add file file2
% hg commit -m "init"
% cd ..
% hg clone a b
updating working directory
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
% cd b
% ls -al
total 8
drwxr-xr-x 3 hoge hoge 5 10 27 21:44 ./
drwxr-xr-x 8 hoge hoge 10 10 27 21:44 ../
drwxr-xr-x 3 hoge hoge 9 10 27 21:44 .hg/
-rw-r--r-- 1 hoge hoge 40 10 27 21:44 file
-rw-r--r-- 1 hoge hoge 40 10 27 21:44 file2
%

554 ：デフォルトの名無しさん：2008/10/31(金) 11:56:13

>>553
パーミッションは保存されません。
hgに限らず、SubversionやVSSでもパーミッションは保存されません。
パーミッションはリビジョン管理システムの外側にある概念です。

555 ：デフォルトの名無しさん：2008/10/31(金) 11:58:59

>>554
Subversionはpropertyとして保存してくれるんだが。

556 ：デフォルトの名無しさん：2008/10/31(金) 13:28:25

だからなに？って話

557 ：デフォルトの名無しさん：2008/10/31(金) 14:48:20

>>556
>パーミッションはリビジョン管理システムの外側にある概念です。
というのが大間違いっていう話。

558 ：デフォルトの名無しさん：2008/10/31(金) 16:33:51

Subversionが自動的にパーミッション保存してくれるなんて初めて聞いたんだが

559 ：デフォルトの名無しさん：2008/10/31(金) 22:01:35

sccsは保存してくれたなぁ、と古い話。

560 ：デフォルトの名無しさん：2008/10/31(金) 22:04:06

svnが保存するのは実行ビットだけであってる?

561 ：553：2008/10/31(金) 23:30:12

hgのソースをみてみたら
どうもexec bitとsymlinkしかあつかえないようだ。

562 ：デフォルトの名無しさん：2008/10/31(金) 23:41:03

なんか問題あんの？
hook で chmod すればそれで終わりじゃん

563 ：デフォルトの名無しさん：2008/11/02(日) 09:12:41

hg はパーミッションは保持しないクソツール、と。

564 ：デフォルトの名無しさん：2008/11/02(日) 11:19:53

ここで煽ってみたところでなにも変わりはしないぞ

565 ：デフォルトの名無しさん：2008/11/02(日) 12:07:38

そもそも644になって問題がある開発環境なんて存在するのか？

566 ：デフォルトの名無しさん：2008/11/03(月) 01:06:15

>>565
というより、SCMとしての機能を考えると、実行属性以外のパーミッションとかACLとかを保存される方が困る気がする。

567 ：デフォルトの名無しさん：2008/11/03(月) 02:53:28

OSやfsによってマチマチだからなぁ

568 ：デフォルトの名無しさん：2008/11/03(月) 13:01:37

POSIX標準くらいサポートしてもバチは当たらない

569 ：デフォルトの名無しさん：2008/11/03(月) 14:17:51

属性を用意したからあとは勝手にやってくれって思想だよな

svn:permissionsを追加したってパッチはみつかったけど
設計や互換性の面で却下されてるようだ

570 ：デフォルトの名無しさん：2008/11/04(火) 18:32:59

TortoiseHGでBitbucketでssh経由でpushしたいのですが、上手くいかず困っています。
ToritoiseSVNでは同じようにして上手くいったのですが・・・

やったこと
・Bitbucketのアカウントをとる
・Bitbucketにssh公開鍵を追加
・setting->repogitoryの設定ダイアログにて、Pathのdefaultを
　ssh://(ユーザー名)@bitbucket.org/(ユーザー名)/(project名)/
に設定（＝ .hg/hgrcの[paths] の default = に上記パスを設定することと等価）
・TortoiseHGのpageantを起動し、対応する秘密鍵を追加
・コマンドラインから hg push → pageantで設定してあるのに何故かパスワードを聞かれる　→
　２回ほど入力したら pagelinkが落ちる。
出力：
　*** no suitable response from remote hg[command interrupted]
・GUIの Synchronize... から push 選択
　コマンドラインの時と同様になる

571 ：デフォルトの名無しさん：2008/11/04(火) 18:35:38

>>570
ToritoiseSVNでBitbucketでssh経由でpushする方法kwsk

572 ：デフォルトの名無しさん：2008/11/04(火) 18:49:33

ああ、スマソ。BitbucketではTortoiseSVNは使ってません・・・。
別のローカル鯖でTortoiseSVNのssh+svnで上手くいったという話です。

573 ：デフォルトの名無しさん：2008/11/04(火) 19:11:00

>>570
追記：
・hg push や GUIでsynchroize->push でパスワード聞かれるときは、
ユーザー名@bitbucket.org's password と言われる。
(鍵の場合 passphraseだったはず？)
・puttyで秘密鍵を指定してBitbucket に接続すると、passwordを聞かれ、
アカウントのパスワードや秘密鍵のパスワードを入れても接続できない。

状況がどうもおかしい気がします・・・

574 ：570：2008/11/04(火) 19:53:47

解決しますた。

>・setting->repogitoryの設定ダイアログにて、Pathのdefaultを
>　ssh://(ユーザー名)@bitbucket.org/(ユーザー名)/(project名)/
ここが間違ってました。
正しくは、
　ssh://[email protected]/(ユーザー名)/(project名)/

以下に書いてありました。

Using SSH - Help ? bitbucket.org
http://www.bitbucket.org/help/using-ssh/

リポジトリページの https://をそのままコピペしてssh://に変えていたせいなのと、
上記ページの例をサンプルだからユーザーがhgになってるのかと思ってた・・・

575 ：デフォルトの名無しさん：2008/11/05(水) 23:58:24

mercurialはtransactionを意識しているのにfsyncしないのはなぜか?

576 ：デフォルトの名無しさん：2008/11/06(木) 18:55:10

SubversionからMercurialに変換したいのですが、
hg convert が動かない？のですが、何か必要なものがありますでしょうか？

> hg help convert
hg: unknown command 'convert'

> hg convert
hg: unknown command 'convert'

TortoiseHgの付属のhgです。

577 ：576：2008/11/06(木) 18:56:00

追記です。

> hg -v
Mercurial Distributed SCM (version 1.0.2+tortoisehg)

578 ：576：2008/11/06(木) 19:12:52

Mercurial.iniに以下を書き込んだら hg convert 自体はうごくようでした。

[extensions]
hgext.convert=

ConvertExtension - Mercurial
http://www.selenic.com/mercurial/wiki/index.cgi/ConvertExtension

ここ読め、オレ・・・

579 ：デフォルトの名無しさん：2008/11/06(木) 20:03:02

hg convertで、Subversionリポジトリからコンバートしているのですが、
もしかして、日本語ログを含んでいると壊れますか？

変換後のリポジトリをTortoiseHgのView Change Logで見ると、
アスキーのみのログのところでは問題なく履歴が見られますが、
日本語ログのリビジョンでは、まったく異なる履歴が表示されます。
（ファイル一覧、差分などがsvnのとは異なります）

これを回避して日本語ログのものもコンバートすることはできないのでしょうか？

580 ：デフォルトの名無しさん：2008/11/06(木) 20:28:33

>>579
TortoiseHgのことは知らないけど、Unix上では日本語ログもきれいに変換され
たよ

581 ：579：2008/11/06(木) 20:48:48

hgsvnも試したけど、hgimportsvnはおｋ。
hgpullsvnが、以下のエラーで途中死亡します orz

transaction abort!
rollback completed
abort: decoding near '縺阪↑縺・ｈ縺・↓菫': 'utf8' codec can't decode byte 0x82
in position 138: unexpected code byte!

>>580
ええ、まじすかー。

svnの日本語ログが変なのかなあ？TortoiseSVNで入れたログのはずですけど

582 ：579：2008/11/06(木) 21:02:40

2008-09-15 - kokiyaの日記
http://d.hatena.ne.jp/kokiya/20080915

こちらのサイトの

> 2.hgsvnの文字コードの変更

を行うと上手くいったような気がしました。
TortoiseSVNでのログはUTFとかで入ってないのかなぁ？
今時間がないので後でまた確かめて見ます。

583 ：579：2008/11/07(金) 07:59:05

日記みたいで、すいません。

hgsvnでsvnからhgへの変換が上手くいったかなーと思ったのですが、
trunk指定すると branchesとかtags 考慮してくれない orz
trunkの親ディレクトリを指定すると、今度はtrunk,branches,tagsと全部できてしまうし・・・

やっぱり、svnと連携するためのものか、これは・・・。

hg convertでなんとか変換する方法を模索したほうがよいようですね。

584 ：579：2008/11/07(金) 08:36:28

>>579の件ですが、
どうやら、壊れると思っていたsvnリポジトリは、hg convert で変換後、
問題のあるリビジョンを hg log -r2 -p などで見ると特に問題ない様子でした。
TortoiseHgのView Changelogのバグ？みたいですね。

585 ：デフォルトの名無しさん：2008/11/07(金) 17:27:47

git rebase origin
を実行すると
README.txt: needs update
とでてくるのですが、これはどういう意味ですか。
README.txtは変更されているのですが、updateが必要というのがよくわかりません。
またこのような状態のときにgit rebase originを問題なく実行するにはどうしたらいいですか。

586 ：デフォルトの名無しさん：2008/11/07(金) 23:37:48

>>583
そもそもsubversionにタグやブランチがないのが原因

587 ：デフォルトの名無しさん：2008/11/08(土) 03:27:23

>>585
README.txtを変更したままなんじゃない？
変更してるファイルがある状態ではrebaseは出来ないよ。
README.txtをコミットするかresetするかstashに追い出すかしてからrebase。

588 ：デフォルトの名無しさん：2008/11/08(土) 04:22:58

>>586
cvs done wrong

589 ：デフォルトの名無しさん：2008/11/08(土) 10:25:48

もっとも使われているらしいsvnはhgやgitよりもそんなに優れているの？

590 ：デフォルトの名無しさん：2008/11/08(土) 11:56:21

優劣ではなくそれぞれに特徴があるんだから、好きなの使えばいい

591 ：デフォルトの名無しさん：2008/11/08(土) 18:40:11

ここ最近のsvnマンセー祭りに吐き気を感じているアルファギークは多いだろうね

592 ：デフォルトの名無しさん：2008/11/08(土) 18:49:39

gitを使うぜみたいな話は最近目に余るようになってきたが、
いまさらsvnマンセーなんて言い出してるトコあるか?

593 ：デフォルトの名無しさん：2008/11/08(土) 18:54:09

アルファギークとかいっちゃってるやつに吐き気を感じる

594 ：デフォルトの名無しさん：2008/11/08(土) 19:29:14

svnマンセーはないだろうｗ
素晴らしい所は、ToritoiseSVNの完成度の高さぐらいだな。

595 ：デフォルトの名無しさん：2008/11/08(土) 19:37:27

アルファギークとか、スイーツ（笑）と同類だろ

596 ：デフォルトの名無しさん：2008/11/08(土) 20:58:46

嫉妬丸出しのレスばかりで笑った

>>593
底辺で蠢いてる奴発見ｗ

アルファギークはもう何歩先も行ってるからｗ

597 ：デフォルトの名無しさん：2008/11/08(土) 22:28:22

Pythonがsvnから移行したがってるようだけど
BazaarになるかMercurialになるか……もしかしてGitもあり?

598 ：デフォルトの名無しさん：2008/11/08(土) 22:28:58

集中管理の svn でも、「なんか変なツール」とか言われてるのに
このレベルで分散システムとか絶対無理だな、うちは

599 ：デフォルトの名無しさん：2008/11/08(土) 22:32:22

Windowsを軽視していないPythonなら、gitはまずないだろう。
MercurialがPython製ということを考えると、Mercurialが優勢ではなかろうか

600 ：デフォルトの名無しさん：2008/11/08(土) 22:35:59

>>599
BazaarもPython製ですよ

↓ソース。まだ検討始まったばかりだけど
ttp://www.python.org/dev/peps/pep-0374/

601 ：デフォルトの名無しさん：2008/11/08(土) 22:54:22

svnからの移行を検討するなら
　遅くてもレポジトリ効率で選ぶならbazaar
　そこそこ速くて使いやすさで選ぶならhg
　速くて機能で選ぶならgit

602 ：デフォルトの名無しさん：2008/11/08(土) 22:56:17

pythonで書かれているツールってことでbzrが有利だろうな

603 ：デフォルトの名無しさん：2008/11/08(土) 23:07:35

>>602
MercurialもPython製ですよ

604 ：デフォルトの名無しさん：2008/11/08(土) 23:34:12

Mercurialが優勢ということか

605 ：デフォルトの名無しさん：2008/11/09(日) 01:14:45

水銀党なのでhgの一択なのだが・・・

606 ：デフォルトの名無しさん：2008/11/09(日) 02:06:54

UNIX系で使って他(Windowsとか)を、それほど考慮しないとか
LinuxやLinusが個人的に嫌いじゃなかったら git
上記に当てはまるなら、他かな？
あてはまる人が結構いるから分かれるんだが

607 ：デフォルトの名無しさん：2008/11/09(日) 02:11:00

分散型って、ゲーム開発みたいに画像などのバイナリデータが容量のほとんどを
占めてスナップショットでも数ギガに行くようなプロジェクトでも、 Subversion より良いの？

それともプログラムソースがメインなプロジェクトに限って良いの？

608 ：デフォルトの名無しさん：2008/11/09(日) 02:18:36

607じゃないが、分散型に興味がある。
今までcvsとsvnしか使ったことがないが、どんなときにどんなメリットがあるのか。
またどんなデメリットがあるのか。
どんな点に注意して使えばよいのか。
そこら辺を具体的に解説したページはないだろうか？

「慣れろ」と言われるかも知れないが、
誰も知らない状態でいきなり本番プロジェクトに導入は出来ないし、
一人gitとかで試してみてもあんまり意味なさそうで・・・

609 ：デフォルトの名無しさん：2008/11/09(日) 02:27:43

分散型のメリット
すべてを手許に置けるのでオフラインででも開発可能でマージもバックアップも気楽にできる

分散型のデメリット
オリジナルの証明が難しい(事実上無い)

610 ：デフォルトの名無しさん：2008/11/09(日) 02:34:01

結局巨大バイナリを一番上手に扱えるのはどれ？
どうせテキストなんかサイズも小さいしある意味バイナリだし。

611 ：デフォルトの名無しさん：2008/11/09(日) 03:48:00

>>607-608
テキスト向きかバイナリ向きかっていうのは集中型か分散型かの差っていうより
ツールごとの差が大きい。開発形態が伽藍的かバザール的か、開発者が一箇所に
いるのか離れてるのかって観点で選んだほうがいいと思ってる。

会社である程度きっちり設計して2～3人で実装していくって形態ならsvnで十分まわせてるけど、
開発者が数人以上いるOSSのコントリビュータって立場のときはまじ分散型導入してくれって感じ

612 ：608：2008/11/09(日) 07:13:50

>>609
「オリジナルがない」という点は大きなデメリットだと思うのですが使用していてどうでしょうか？
皆が同じソースを見ることが出来ない＝AさんとBさんで同じソースについて認識が異なってしまう　ということで。
Aさん：rev329で試験したけど、これこれこういう動作がおかしいよ。直しておいて。
Bさん：それrev332で修正済みです
みたいな会話をどうやるのかがわからない。
仕事の現場なら非常に良くある話だと思うのですが。
メリットの方はsvn+svk(使ったことはないですが)でも可能なような。

>>611
仕事のプロジェクトなので伽藍方式オンリーですね。
開発者は大体同じ拠点にいますが、東京3人北海道3人大阪・・・ということもありました(svnで問題なく回っていました)。
2～3人で実装していく現場ってのは経験無いですなぁ。実装チームは5～10人が普通。

613 ：デフォルトの名無しさん：2008/11/09(日) 07:31:10

>>612
あなたのような「分散型使ってないけどどうなの？」っていう人は定期的に見かけるけど
チュートリアル見ながら触ってみるぐらいやってみたらどうだろう。たいした手間じゃないよ。

＞メリットの方はsvn+svk(使ったことはないですが)でも可能なような。
私はGitの前にsvkを使ってたけど、svkは遅すぎると思った。

あとオリジナルが無いという点については、Gitの場合はツリーに一意なIDが付くので問題ないと思う。

614 ：デフォルトの名無しさん：2008/11/09(日) 07:35:45

>>612
> 「オリジナルがない」という点は大きなデメリットだと思うのですが使用していてどうでしょうか？

オリジナルは決めとけばいいんじゃないか。集中管理のときと同じように、オリジナル用のサーバーってのを。
議論はそのサーバーにあるものに対してする。
push し忘れとか、pull した後 update し忘れとかが当面の問題になるんじゃないかなあ。

Mercurial 導入を提案しようかと自分で試用中だけど、ほかの人たちが使いこなせるとは思えないので、
今までどおり CVS にしようと思ってる。プロジェクト(リポジトリ)ツリーの好きなところからちぎって
持ってきて組み合わせられるような SCM はほかにはなさそうだし。

615 ：デフォルトの名無しさん：2008/11/09(日) 08:50:25

オリジナルが無いって語弊があるんじゃない?
svnと同じように中央レポジトリを作ればそれがオリジナルになる。

616 ：デフォルトの名無しさん：2008/11/09(日) 09:11:32

>>605
そいやmercurialだけ単独スレないな

617 ：デフォルトの名無しさん：2008/11/09(日) 12:03:16

Linux板にgitスレあったのか。CVSはUNIX板だし…。
スレも分散管理ですか。

618 ：デフォルトの名無しさん：2008/11/09(日) 12:12:36

>>616
何がそいやなんだｗ

619 ：デフォルトの名無しさん：2008/11/09(日) 12:22:20

どうもありがとうございます。
>>587
>変更してるファイルがある状態ではrebaseは出来ないよ。

この制約はどういう理由からきてるんでしょうか。
変更したファイルがあっても merge はできるんだから、rebase ぐらいできてもよさそうですが。

620 ：デフォルトの名無しさん：2008/11/09(日) 12:26:37

上の話が本当なら Python が hg か bzr になるかってのは試金石だな

621 ：デフォルトの名無しさん：2008/11/09(日) 13:31:09

リトマス？

622 ：デフォルトの名無しさん：2008/11/09(日) 13:40:35

普通に考えて分散型の方が良いとしか思えないなあ

623 ：デフォルトの名無しさん：2008/11/09(日) 13:51:49

>>622
bazaar＝分散型とはいえない

624 ：デフォルトの名無しさん：2008/11/09(日) 14:11:09

>>623
くわしく

625 ：デフォルトの名無しさん：2008/11/09(日) 14:18:44

>>608
分散型はローカルでもバージョン管理ができるというメリットがある。

よくプロジェクト全体でSVN使っていてローカルではRCSというような
使い方をしている人がいるが、分散型なら1つのシステムで対応できる。

626 ：デフォルトの名無しさん：2008/11/09(日) 15:00:35

>>625
>よくプロジェクト全体でSVN使っていてローカルではRCSというような
>使い方をしている人がいるが、分散型なら1つのシステムで対応できる。

GitやMercurialは、RCSの代わりに使えるのがいいよね。
プロジェクト全体はSVNで管理して、自分用のブランチはGitやMercurialで管理するのが楽でいいや。

627 ：デフォルトの名無しさん：2008/11/09(日) 15:10:32

>>626
Bazaar も仲間に入れてあげてください(´・ω・｀)

628 ：デフォルトの名無しさん：2008/11/09(日) 15:14:54

>>624
http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#workflows

629 ：デフォルトの名無しさん：2008/11/09(日) 15:27:23

俺いままでずっとバザールって読んでたよ
ダサイ名前だと思ってた

630 ：デフォルトの名無しさん：2008/11/09(日) 15:46:53

分散型はバージョン管理の入門用にうってつけなんだよね
スタンドアロンで使う場合最も敷居が低い

631 ：デフォルトの名無しさん：2008/11/09(日) 15:54:20

>>629
え、違うの?なんとなくエリックレイモンドの
「伽藍とバザール (The Cathedral and the Bazaar)」
から来てるんじゃないかと思ってたが。

632 ：デフォルトの名無しさん：2008/11/09(日) 16:07:50

>>618
そういえば →(口語化)→ そういやぁ →(短縮)→ そいや
かけ声じゃないよｗ

633 ：デフォルトの名無しさん：2008/11/09(日) 16:11:27

>>619
rebaseは、reset ＋ cherry-pick×n回を自動化してるだけだから、マージとは違う。
たしかに、現在の変更をstashしてrebase後にstashから戻す、という作業も、
rebaseで自動でやってくれれば、もっといいかもしれないね。

634 ：デフォルトの名無しさん：2008/11/09(日) 17:26:06

http://www.thefreedictionary.com/bazaar
敢えてカタカナにするなら、「バザール」以外にどうしろというのだろう。

635 ：デフォルトの名無しさん：2008/11/09(日) 17:30:15

ござーる

636 ：デフォルトの名無しさん：2008/11/09(日) 17:44:37

>>632で>>618の意味がわかってﾜﾛﾀ

637 ：デフォルトの名無しさん：2008/11/09(日) 17:44:48

おおいなるマンション　セザーーール
というのがあったな。

638 ：デフォルトの名無しさん：2008/11/09(日) 19:20:30

>>633
ありがとうございます。
変更したファイルがある状態で rebase したいとき、stashする方法と、ダミー commit + reset HEAD^ を使う方法を思いついたんですが、
どっちがいいと思いますか。
つまり

$ git stash
$ git rebase origin
$ stash apply
$ stash clear

または

$ git ci -a -m 'dummy'
$ git rebase origin
$ git reset HEAD^

のどっちがいいかという話です。
Git はまだよくわからんので、たとえばダミーでもcommitするのはイクナイ！とかあれば教えてください。

639 ：デフォルトの名無しさん：2008/11/09(日) 19:35:26

セザールはカエサル(シーザー)のフランス語読み。

640 ：デフォルトの名無しさん：2008/11/09(日) 20:19:12

おおいなるマンションバザールでござーるの巻

641 ：デフォルトの名無しさん：2008/11/09(日) 22:20:02

github についてなんですが…
誰か他人のプロジェクト
(1) git://github.com/誰か/プロジェクト.git
をforkしてできた
(2) git://github.com/自分/プロジェクト.git
をいじっても、(1)にpull requestを出してマージされない限りは
(1)に反映されることはないってことでいいんでしょうか？

642 ：デフォルトの名無しさん：2008/11/10(月) 09:57:54

hg qinit+qnewした状態でhg pushすると面倒なことになるんだけど
安全装置が付いてないのはなぜ?

643 ：デフォルトの名無しさん：2008/11/10(月) 11:03:26

>>641
はい、そうです。
他のひとのリポジトリを汚さないためのforkなので、当然です。
他のひとのリポジトリに書き込みしたいなら、そのリポジトリへのアクセス権をもらう必要があります。

644 ：デフォルトの名無しさん：2008/11/10(月) 19:27:04

>>628
ごめん、何がいいたいのかわかんない。
３行でまとめてくれ。
これじゃあBazaarのよさがわかんない。

645 ：デフォルトの名無しさん：2008/11/10(月) 23:30:17

>>642
面倒な事についてkwsk

646 ：デフォルトの名無しさん：2008/11/11(火) 00:12:47

>>644
リンク先は読んだ？　図解までされてものすごく解りやすかったぞ。

647 ：デフォルトの名無しさん：2008/11/11(火) 07:13:45

>>643
ありがとうございます。
やっぱりそうですよね…
こないだ自分のリポジトリを更新したら、勝手にfork元の
リポジトリも更新されたように見えて焦ったんですが
相手がpullしたってことなんだろうか。。

648 ：642：2008/11/11(火) 12:29:09

>>645 pushじゃなくてpullだった
rm -rf repo myrepo
[email protected]
export HGUSER
hg init repo
cd repo
date >file
hg commit -A -m "start"
hg clone . ../myrepo
hg qinit
hg qnew PATCH
for X in 1 2 3; do
date >>file
hg qrefresh
cd ../myrepo
hg pull
cd ../repo
done
hg glog --style=compact
cd ../myrepo
hg glog --style=compact

649 ：642：2008/11/11(火) 12:30:08

+ hg glog --style=compact
@ 1[qtip,qbase,tip,PATCH] 1a93f26efdf7 2008-11-11 12:27 +0900 alice
| [mq]: PATCH
|
o 0[qparent] c96ce7235e6b 2008-11-11 12:27 +0900 alice
start

+ cd ../myrepo
+ hg glog --style=compact
o 3[tip]:0 1a93f26efdf7 2008-11-11 12:27 +0900 alice
| [mq]: PATCH
|
| o 2:0 b3c2e24e33e9 2008-11-11 12:27 +0900 alice
|/ [mq]: PATCH
|
| o 1 b6fb28c1e4ff 2008-11-11 12:27 +0900 alice
|/ [mq]: PATCH
|
@ 0 c96ce7235e6b 2008-11-11 12:27 +0900 alice
start

650 ：デフォルトの名無しさん：2008/11/11(火) 22:45:30

subversionでｺﾐｯﾄしてる内容を、Google Codeみたくブラウザでも見れるようにしたいんだけど、
それってTracﾅﾝﾁｬﾗみたいなのに移行しないとダメ？

651 ：デフォルトの名無しさん：2008/11/11(火) 22:47:15

>>650
WebDAV

652 ：デフォルトの名無しさん：2008/11/11(火) 22:48:13

ﾎｹﾞｰｯ!!!ごめんなすって！viewﾅﾝﾁｬﾗってので出来る感じね！
ｺﾞﾒﾝﾈｺﾞﾒﾝﾈ

653 ：デフォルトの名無しさん：2008/11/11(火) 22:49:04

>>651
ありがDo！＿|＼○_

654 ：デフォルトの名無しさん：2008/11/11(火) 22:59:27

>>646

>>623
>>>622
>bazaar＝分散型とはいえない

>>628のリンク先を読んだけど、
bazaarはやはり分散型だと思うのだが、
分散型ではないという根拠は何？

655 ：デフォルトの名無しさん：2008/11/11(火) 23:04:02

>>654
分散型を分散型として使わなくても良いって意味じゃね？

656 ：デフォルトの名無しさん：2008/11/11(火) 23:45:26

>>638
どちらでもいいと思いますよ。
私は普段git-svn使ってるので、よくrebaseすることになるんだけど、最近使うのはstashかな。
少し前のバージョンまではstashが無かったので、ダミーコミットしてやってましたが、
stashの機能自体、内部では同じようなことをやってるんだと思う。ソース見てないですが。

657 ：デフォルトの名無しさん：2008/11/12(水) 01:19:03

すごい遅レスだけど、分散型のメリットは一言で言うなら、
「リポジトリ同士で」履歴のマージ等の操作ができるという点では。

非分散型=集中型でも、手元にリポジトリ作ればローカル管理はでき、
ファイル自体は他のリポジトリに移せるけれども、
履歴等を他のリポジトリに移すとかってのはできない。

違うかな?

658 ：デフォルトの名無しさん：2008/11/12(水) 01:42:50

分散型は分散した運用が可能な設計であるが、集中型の運用も可能ということだよね。
反対に集中型が基本のシステムで分散的な運用が必要になる時はものすごく苦痛。

集中型のシステムで開発してたのが、会社合併、アウトソーシング等で分散型の運用が
必要になったことが二回ほどあるがかなり苦労した。　

659 ：デフォルトの名無しさん：2008/11/12(水) 03:48:01

使ったことないが、bzrにはwikipediaにこういう記述があるから

> 中央サーバを使わない純粋な分散型バージョン管理システムと比べて、
> Bazaarは中央サーバ有り・無しの両方での動作をサポートしており、
> 同じプロジェクトに対し同時に両方の方法を使うことも可能である。

>>623が言いたかったのはそのこと(そういう機能？)じゃないか。

660 ：デフォルトの名無しさん：2008/11/12(水) 07:41:00

自分の作業するところは細かくコミットしたいから、こんなことやってる。
ちょっと面倒だし、もっと良い方法はあると思うけど。。

中央サーバ-からcheck out - A
coしたやつからbranch 　　 - B
Bをいじって適当にコミット
適当なところで、AでBの変更を取り込み
Aをコミットして中央サーバへ

更新を持ってくるときは、Aでupdateして, Bでpullする。

661 ：デフォルトの名無しさん：2008/11/12(水) 18:03:09

>>659
>> 同じプロジェクトに対し同時に両方の方法を使うことも可能である。
これすごいな。bzr++

662 ：デフォルトの名無しさん：2008/11/13(木) 01:42:08

集中型の利点は、チェックアウト→コミットの間の
ネットワーク転送量が少ない（記憶領域の使用量も少ない）ということかな。

分散型だと、リポジトリ全体を持ってきたりして、転送量がすごいことになったりするでしょ。
たとえば100GBのリポジトリをcloneすることを考えてみて。

663 ：デフォルトの名無しさん：2008/11/13(木) 01:55:40

　　　　　 |
　　＼　　__　　／
　　＿　（ｍ）　＿ﾋﾟｺｰﾝ
　　　　　|ミ|　　　　　torrentみたいに分散させれば
　　／　｀´　＼
　　　　　('A`)
　　　　　ノヽノヽ
　　　　　　　くく

664 ：デフォルトの名無しさん：2008/11/13(木) 06:44:35

CoreserverにTracってのを入れてみたいんだけど難しくて判んないよ～(´･ω･`)

665 ：デフォルトの名無しさん：2008/11/13(木) 07:02:40

>>664
レンタルサーバーか。
コンパイルしてホームにつっこむだけじゃないの？

666 ：デフォルトの名無しさん：2008/11/13(木) 08:04:20

Tracは依存関係がものすごいからな。
レン鯖の制限があると苦労しそうだ

667 ：デフォルトの名無しさん：2008/11/13(木) 10:08:28

Tracの話題はこっちじゃないかな

【バグ管理】 BTS使ってる？【追跡ﾞ】２
http://pc11.2ch.net/test/read.cgi/tech/1163173901/

668 ：デフォルトの名無しさん：2008/11/13(木) 10:59:24

>>667
ありがとう。いってきまーす。なにかヒントがあると良いな～(´･ω･`)

669 ：デフォルトの名無しさん：2008/11/13(木) 11:25:05

mantisっていうのは、TracやGoogle Codeみたいにファイル変更の差分が見れるものではない？(´･ω･`)

670 ：デフォルトの名無しさん：2008/11/13(木) 16:47:29

>>662
それ分散型か集中型かに関係なく仕組みによる。独立(standalone)なら全部取得だし、軽量(lightweight)なら一部のみ取得。

svnは軽量チェックアウト。
mercurialは独立ブランチ。
gitは軽量ブランチ。
bzrは独立チェックアウト(bzr co)、軽量チェックアウト(bzr co --lightweight)、独立ブランチ(bzr branch)。軽量ブランチはbzr cbranch --lightweightやbzr branch --stackedが当てはまるのかなぁ、良く分からね。

671 ：デフォルトの名無しさん：2008/11/13(木) 16:51:35

ああ、bzr cbranch --lightweightは勘違い。
他にも間違いありそうだから補足頼む。

672 ：デフォルトの名無しさん：2008/11/14(金) 01:35:44

日本語ディレクトリとかファイル名をバリバリに使ってるプロジェクトを
分散型バージョン管理システムで管理したいのですが、何を選択すべきでしょうか？
ちなみに環境はwindowsです。
（svkは試したのですが、あれは重すぎたのでそれ以外で）

673 ：デフォルトの名無しさん：2008/11/14(金) 06:51:19

使えるかどうかだったらhg, git, bzrのどれも使える。
ファイル毎にファイル名のencodingが違うとどれもダメだけど。
windowsだけならcp932だけになるのでどれもOK。
ただしTortoiseSVNのようなものを期待しているなら、
Hgにあるけどhgkだけが表示上は文字化けする、けど問題なく使えてる。
日本語ファイル名を使いたいならSVNが一番いいけど、
分散型でどれを選択すべきかはどれも微妙。

674 ：デフォルトの名無しさん：2008/11/14(金) 12:57:31

svn, bzrは基本的に問題ないだろう。

675 ：デフォルトの名無しさん：2008/11/14(金) 23:29:09

http://sourceforge.jp/forum/forum.php?forum_id=16362
＞新規プロジェクトでは Git が標準で有効、CVS が無効に変更されました。

なんかすごいな。

676 ：デフォルトの名無しさん：2008/11/14(金) 23:32:56

>>675
おいおい、本家ではGit対応してなかったはずじゃ…と思ったら書いてある記事があった(下)。とはいえgithubやlaunchpadのように使えないと旨味が少ない気が。
SourceForge.JP、Gitのサポートを開始
http://www.itmedia.co.jp/enterprise/articles/0811/14/news055.html

677 ：デフォルトの名無しさん：2008/11/14(金) 23:37:01

gitはWindowsで日本語ファイルはダメダメですよ
その前に、gitは日本語ファイル名を使うようなユーザー間ではまともに使えないと思うよ

678 ：デフォルトの名無しさん：2008/11/14(金) 23:44:59

集中型は svn、分散型は git になるのが加速されるのだろうか？

679 ：デフォルトの名無しさん：2008/11/14(金) 23:45:45

gitはないな
つうかいつまで集中型使われるんだ

680 ：デフォルトの名無しさん：2008/11/14(金) 23:46:17

　　　　　 ☆　ﾁﾝﾁﾝ　〃 ∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　ヽ　＿＿_＼（＼・∀・）　＜　Bazaarの対応まだー？
　　　　　　　＼＿／⊂　⊂＿ )　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／￣￣￣￣￣￣／|　　
　　　　　　　　|￣￣￣￣￣￣￣|　 |　

681 ：デフォルトの名無しさん：2008/11/14(金) 23:48:41

これで日本語ファイルのエンコード対応パッチも投げられるか。

682 ：デフォルトの名無しさん：2008/11/15(土) 00:24:51

国際化するなら、内部ではunicodeで処理、それぞれの環境でファイル名変換が妥当？

683 ：デフォルトの名無しさん：2008/11/15(土) 00:35:10

集中型はずっと使われると思うよ、svnで充分なこと多いし。

分散型はしばらく戦国時代だろうな。天下統一は遠いとみた。

684 ：デフォルトの名無しさん：2008/11/15(土) 01:04:10

Pythonで実装されてるやつは、Python3.0ベースになれば
文字コード問題は解決されそうだけどなぁ。

俺は、hgもgitも天下を取らないうちに次の新星が出てきて
そっちが天下を取ると思っているw

685 ：デフォルトの名無しさん：2008/11/15(土) 06:22:47

>>684
十分ありえそうな話ですね。
つうかgitでもhgでもbzrでもいいから、
一番優れた物がさっさと天下取ってほしい。
戦乱状態だと、使いつづけるのに不安が残る。

686 ：デフォルトの名無しさん：2008/11/15(土) 08:47:33

集中型は今はsvnって決まったも同然だから楽なんだけどね

687 ：デフォルトの名無しさん：2008/11/15(土) 12:52:08

>>677
Windows(Cygwin)のgitで日本語ファイル名を普通に使ってるけど

688 ：デフォルトの名無しさん：2008/11/15(土) 13:27:15

でも、やっぱプロジェクト内に浸透させるにはtortoise*が必要だわ

689 ：デフォルトの名無しさん：2008/11/15(土) 18:38:18

>>687
gitで日本語周りどういう風に運用してます？参考までに教えてください。

私が以前試したときの話ですが、

・UTF-8対応ターミナル用意した上で(もしくは、nkfとか通す前提で)
・コミットログは UTF-8
・エディタ(GIT_EDITOR)はデフォルトでUTF-8で起動させる必要がある
（UTF-8で起動できるソフトを使う。例：GreenPadなど）
・日本語ファイルは？ >>312 の問題があって、ここでオレはあきらめてしまった口だけど・・・
SJISだとWindows上ではOKだけど、
別プラットフォームだと×とかだったりしそうで

俺の周りだと、UTF-8ターミナル+cygwin+コマンドラインという環境用意させるのと、
日本語ファイル使う運用が矛盾をきたしたので結局やめてしまった。
（個人的にはオプソとかの開発とかパッチ作ったりには使ってる）

690 ：デフォルトの名無しさん：2008/11/15(土) 23:28:10

>>689
普通に、と書いてしまいましたが少しウソ。
Cygwin は ntf-8パッチの dllを使っています。
git は core level でファイル名の encode は考慮しません。
なので、ファイル名は utf-8 で統一します。
だた、これは subversion 等でも同じこと。
ツール群が良きに図らってくれるか、自分でそうするかという違い。
結局(ファイルの中身以外)utf-8で統一するなら、何使っても問題無い
ということですけど。

691 ：デフォルトの名無しさん：2008/11/16(日) 00:28:43

> Cygwin は ntf-8パッチの dllを使っています。

はあ。そうですよね。まだ対応してませんもんね。

> ツール群が良きに図らってくれるか、自分でそうするかという違い。

こりゃまた「敷居」って言葉を考えさせる発言ですね。

692 ：デフォルトの名無しさん：2008/11/16(日) 00:46:20

>>690
Subversionはファイル名のエンコードはロケールに合わせてくれるので、
日本語ファイル名はOSXでのNFD問題以外は問題はないな。

> 結局(ファイルの中身以外)utf-8で統一するなら、何使っても問題無い
これはOSXとLinuxで日本語の濁点を含むファイル名を利用してみれば、
そんなに簡単ではないということが分かるハズ。

693 ：デフォルトの名無しさん：2008/11/16(日) 00:51:10

http://sourceforge.jp/forum/forum.php?forum_id=16362

694 ：689：2008/11/16(日) 00:59:26

>>690
なるほど、過去レスでも出てたCygwinのUTF-8パッチですね。
これは、試してみないとあかんなあ。

>>692
そこまで考えてなかたよ

>>693
ニュース: Gitサポートを開始しました - SourceForge.JP - SourceForge.JP
http://sourceforge.jp/forum/forum.php?forum_id=16362
ソースフォルゲは相変わらず、Windows軽視だよなあｗ

695 ：デフォルトの名無しさん：2008/11/16(日) 02:28:02

Windows（笑）

696 ：デフォルトの名無しさん：2008/11/16(日) 05:40:03

>>684
Mercurialは3.0待ちかもしれないけど、Ｂａｚａａｒはもう日本語まったく問題ないよ。
ＴｏｒｔｏｉｓｅＢｚｒも日本語ちゃんと扱えてる。
(参考) ttp://dsas.blog.klab.org/archives/51344422.html

697 ：デフォルトの名無しさん：2008/11/16(日) 09:25:01

全角英数字使う奴は信用ならん

698 ：デフォルトの名無しさん：2008/11/16(日) 09:30:12

とはいえBzrにTotoiseがでたんだね。試してみる価値はありそう。
あとは速度がhg以上なら乗り換えるんだが。

699 ：デフォルトの名無しさん：2008/11/16(日) 10:21:09

>>696
やっぱり日本語だめだったよ。

TortoiseBzrで Init して日本語ファイル名をTortoiseBzrでaddし、
ファイルの中も日本語にしした結果、
TortoiseBzrでdiff → ファイル名は日本語で表示されるが中身が文字化け
cmd.exe上でdiff→中身は日本語で表示されるがファイル名が文字化け
ちなみに1.9のレポジトリフォーマットにしてみた。

あとGeneral Bazaar Options.. が開かないがバグかな。
それと、デスクトップ上でInitしようとしたらできなかった。
空文字入りパスは対応できない様だ。

ちょっと使っただけでこれだけ不具合が見つかる様じゃ、
まったく実用に耐えないね。まぁ、今後に期待はするが。

700 ：デフォルトの名無しさん：2008/11/16(日) 11:09:39

>>696
MercurialはUnicodeベースに変更できるからもう問題ないだろ
どこに問題があるんだ？

701 ：デフォルトの名無しさん：2008/11/16(日) 11:22:35

TortoiseBzr入れてみたんだが、そもそも日本語フォルダで Init できないのは
なんか設定ミスってる？

702 ：デフォルトの名無しさん：2008/11/16(日) 11:29:59

つかこれだけ国際化についての問題意識が広まっていながら
この体たらくって一体なんなんだろうね

703 ：デフォルトの名無しさん：2008/11/16(日) 11:44:30

海の向こうの変な文字のことなんて気にしないニダ

704 ：デフォルトの名無しさん：2008/11/16(日) 12:16:05

海の向こうはマジで
「『漢字』などという象形文字を使っている国は文化レベルが低い」
と思ってるらしいぜ。

705 ：デフォルトの名無しさん：2008/11/16(日) 12:29:26

自分らの文字は letter で漢字は character ですって。笑わせますよね。

706 ：デフォルトの名無しさん：2008/11/16(日) 12:38:03

よく体に漢字を彫ったりしてるじゃんｗ
自分にないものは格好良く見えるのか

707 ：デフォルトの名無しさん：2008/11/16(日) 12:39:08

全角英数字使う奴は信用ならないというのは正解だったということか。

708 ：デフォルトの名無しさん：2008/11/16(日) 12:43:00

>>706
あれはイラスト

709 ：デフォルトの名無しさん：2008/11/16(日) 13:20:05

>>699
あー、diffは仕方ないね。Subversionだって同じだろ？

ああ、「ファイル名」は日本語に対応しているけど、「ファイルの内容」は
文字コードとか気にせずにそのまま記録しているだけだから、
文字コードの自動認識してくれないdiffで見ると中身文字化けする。

ＷｉｎＭｅｒｇｅのような、文字コードを自動認識してくれる外部diffを使わないと
いけないな。

710 ：デフォルトの名無しさん：2008/11/16(日) 13:44:17

デスクトップ上でも空文字(スペース？)入りパスでもInitできたけど、なにが違うんだろ

711 ：デフォルトの名無しさん：2008/11/16(日) 14:28:10

>>709
すべてwindows上でやってるのにそれはないだろ。
subversionで同じ事やっても文字化けなどしないよ。

712 ：デフォルトの名無しさん：2008/11/16(日) 15:38:08

文句言うだけじゃなくて、日本人がもっと開発に参加して
日本語バッチリにしてやろうぜ。

713 ：デフォルトの名無しさん：2008/11/16(日) 15:50:37

Tortoise BZR doesn't support repos with non-latin characters in path
https://bugs.launchpad.net/tortoisebzr/+bug/267098

714 ：デフォルトの名無しさん：2008/11/16(日) 15:55:10

>>711
いやいや、俺Windowsでも普段UTF-8でテキストファイル書くし。
エンコーディングの自動判別していない限り、「たまたま」テキストファイルの
エンコーディングと表示に使うエンコーディングが一致したときに化けずに
表示されるだけ。

715 ：デフォルトの名無しさん：2008/11/16(日) 16:14:08

つーか中国でも普段使いの文字コードはだいたい１つだし、
環境によって文字コードを３種類から使い分ける必要がある国なんて日本ぐらいなんじゃね
日本人が対応するしかないだろ

716 ：デフォルトの名無しさん：2008/11/16(日) 16:18:12

>>700
設定の煩雑さ。

…使ってるけどさ。

717 ：デフォルトの名無しさん：2008/11/16(日) 16:32:36

>>715
何言ってんだ
中国のほうが環境によって使われる文字コードは多いだろ
日本語の EUC-JP(UNIX系),シフトJIS(DOS系),JIS(メール)に対応するものが
中国にもある上、繁体字・簡体字の区別もある

718 ：デフォルトの名無しさん：2008/11/16(日) 16:48:02

http://repo.or.cz/w/TortoiseGit.git

719 ：デフォルトの名無しさん：2008/11/16(日) 17:05:02

>>718
Windowsでまともに動かないのにwww
作ったやつは頭がいかれてんじゃねwww

720 ：デフォルトの名無しさん：2008/11/16(日) 18:46:33

>>717
中国の繁体字簡体字は文字体系そのものが違うから関係無い話
繁体字で保存したテキストを簡体字で読むこともあるとか考えてたなら帰れ

721 ：デフォルトの名無しさん：2008/11/16(日) 22:34:07

>>720
バカの言い訳は見苦しい
そもそも何の話をしてるか理解してるか？

722 ：デフォルトの名無しさん：2008/11/16(日) 22:52:07

>>720

723 ：デフォルトの名無しさん：2008/11/16(日) 22:59:30

>>721-722
何の話をしてるか理解していないようだから言っておくが
中国では繁体字は big5 簡体字は EUC で FA だ
日本のように保存したファイルを別の文字コードに変換して表示したい
＝Windows でコミットしたファイルを Unix でも見たい
と言った状況でも何ら問題無いため文字コードの変換という実装は必要無い
＝現在の実装でも運用にさしたる問題は生じない
＝運用に問題が生じる日本から声を出していかないと開発側には問題が伝わらない
分かったなら俺と一緒に英語メールの書き方勉強しろや

724 ：デフォルトの名無しさん：2008/11/16(日) 23:04:45

簡体字はgbの方が主流。適当に語るのはやめれ。

725 ：デフォルトの名無しさん：2008/11/16(日) 23:10:06

EUC-CN と GB は同じだから。

726 ：デフォルトの名無しさん：2008/11/17(月) 00:00:04

bzrのdiffがコードページを無視してutf8を使ってるという話が、
文字コード自動判別の話になり、
中国語の文字コードの話になって、
文字コードを勝手に変換してプラットフォーム間の差異を吸収して欲しいという話になりました。
終わり。

727 ：デフォルトの名無しさん：2008/11/17(月) 00:06:21

出力時にコンソールのコードページをcp65001にすればいいだけじゃ?

728 ：デフォルトの名無しさん：2008/11/17(月) 00:17:32

中国はどうでもいい。
日本語環境だけが興味あるんだが。

729 ：デフォルトの名無しさん：2008/11/17(月) 00:20:22

日本語環境
svn >> git > hg >> bzr
でFA?

730 ：デフォルトの名無しさん：2008/11/17(月) 00:28:56

svn = bzr > hg = git

731 ：デフォルトの名無しさん：2008/11/17(月) 00:39:26

gitとhgは中身がロケール依存なので個人的にはなしの方向だな

732 ：デフォルトの名無しさん：2008/11/17(月) 01:32:34

gitがその位置ってのはありえないだろう

733 ：デフォルトの名無しさん：2008/11/17(月) 01:34:08

ごめんgitありえないだろうは、>>729ね。

734 ：デフォルトの名無しさん：2008/11/17(月) 07:19:22

おいおい、windows環境だけで化け化けの
bzrはどう見ても最下位だろう

735 ：デフォルトの名無しさん：2008/11/17(月) 09:04:21

>>734
化けて見えるのはdiffの表面上の問題だけで、リポジトリの中身はしっかりしてるから。
diff も、 bzr diff | vim - みたいにエディタで見れば問題ない。

svn, bzr:
　ファイルの内容はそのまま、ファイル名はUnicode
　(Windows と Linux で日本語ファイル名のファイルを行き来させても大丈夫)

git, hg:
　ファイルの内容はそのまま、ファイル名もそのまま
　(Windows と Linux で日本語ファイル名を行き来させるとどっちかで化ける)

736 ：デフォルトの名無しさん：2008/11/17(月) 09:38:33

svnもcygwin版じゃダメだぞ

737 ：デフォルトの名無しさん：2008/11/17(月) 09:44:32

>>736
cygwinはlocaleないからなぁ。。。
UTF-8版cygwinならなんとかなるのかな。

738 ：デフォルトの名無しさん：2008/11/17(月) 12:19:57

>>735
ログは皆UTF-8かな?

739 ：デフォルトの名無しさん：2008/11/17(月) 12:20:23

結局どれやねーん

740 ：デフォルトの名無しさん：2008/11/17(月) 12:36:08

>>739
わかるぞ、その気持ち

741 ：デフォルトの名無しさん：2008/11/17(月) 15:08:35

名前 bzr >>> hg >> git # ギット(笑) 商売の神マーキュリーから取った"気が変わりやすい"(笑)
コマンド名 hg >> git >>>>> bzr # 打ちやすさから。hgとmercurialの差が大きすぎるのは考慮してない。
使いやすさ ??? # 主観入るだろうから省略
Webインターフェース bzr > git >>>> hg # bzrはloggerhead(hgwebの派生)ね。hgwebの使いにくさは異常。
ホスティングサービス bzr >>>> git >>>> hg # launchpadはバグトラッカー付きでいたれりつくせり、githubは普及している、bitbucketは…
拡張性 bzr >>>> hg >> git # gitはC言語だからしゃーねーわな、でもgit-svnの酷さはフォローしない。あとhgは内部APIがショボいとか。プラグインの数の少なさからも裏付けられる。
設計の良さ bzr >> git > hg # 抽象化度
実装の良さ git >>>> bzr > hg # diffやmergeのアルゴリズムとか
SVNとの親和性 bzr >> git >>>>>>>> hg # bzrはbzr-svn、gitはgit-svnで評価。
使用率 git >>>> hg > bzr # Debianのpopconのデータからなので正確では無い
速度 git >>>> hg = bzr(1.9) >>>>> bzr(pack-0.92) # ちゃんと計測していない…。ちゃんと計測したいが…。
将来性 git >>> bzr >>> hg # gitはLinux Kernelで使われ続ける、bzrはUbuntuで使われ続ける、hgは…?
国際化 ??? # どれも完璧じゃない。cygwinに関してはcygwin側の問題だからそちら側で解決してもらえ…と言いたいけど、確か開発元がRHだから無理だろうなぁ(RH/Fedoraは未だに閉鎖的と感じる)。

とりあえず速度厨はgitを、拡張厨はbzrを、どっちつかずはhgを使っておけば良いと思うよ^^

742 ：デフォルトの名無しさん：2008/11/17(月) 15:53:35

たぶん、日本国内だと、日本語解説サイトの数や充実度と、解説本の数で
勝負が決まってしまうと思う。Fedoraが日本でだけ万人向けディストロとして
流行ったみたいに。

743 ：デフォルトの名無しさん：2008/11/17(月) 17:46:56

hg のフォローしておくと、まず Mozilla や Sun では使われてる。
あと、コマンドが少なくて良い。同じことをやるのに迷う必要が無い。
一番良いのが基本的に push pull が HTTP で完結してること。
FW の設定いらんから大概使える。
Tortoise も一応あるし、速度 git 拡張 bzr 可搬 hg ってことにしといて。

744 ：デフォルトの名無しさん：2008/11/17(月) 18:08:02

>Mozilla や Sun では使われてる
いや、そうでなくVCS自体の開発の後ろ盾の話。gitならLinuxのカーネルコミュニティ、bzrならCanonicalだけど、hgはどうだっけか。
>コマンドが少なくて良い
--helpに出てくるコマンド多くね? むしろいくつかの面白いコマンドがあるところがhgの利点だと思うが。
>push pull が HTTP で完結
bzrもgitも対応してね?

745 ：デフォルトの名無しさん：2008/11/17(月) 19:23:02

hg mercurial >> bzr bazaar
ttp://www.google.com/trends?q=hg+mercurial%2Cbzr+bazaar

git >> hg mercurial
ttp://www.google.com/trends?q=git%2Chg+mercurial

git > subversion
ttp://www.google.com/trends?q=git%2Csubversion

subversion >> git (in japan)
ttp://www.google.com/trends?q=git%2Csubversion&geo=JP

746 ：デフォルトの名無しさん：2008/11/17(月) 19:29:59

git って HTTP で完結してたの？

747 ：デフォルトの名無しさん：2008/11/17(月) 19:33:08

>>746
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Bazaar: HTTP, SFTP, FTP, custom, custom over ssh, email bundles, WebDAV (with plugin)
Git: custom, custom over ssh, rsync, HTTP, email, bundles
Mercurial: HTTP, custom over ssh, email bundles (with standard plugin)

748 ：デフォルトの名無しさん：2008/11/17(月) 20:43:18

>>747
FTP, SFTPがあることにびっくりだよBazaar!

749 ：デフォルトの名無しさん：2008/11/17(月) 22:20:07

主観は入りまくりだけど、そこがよい
>>741乙

750 ：デフォルトの名無しさん：2008/11/17(月) 22:39:12

>>735
表面が化けてちゃ、おいしさも半減なわけですが。
いちいちvimでなんかみたくないし、Tortoiseで化けるのは
設定でなんとかなるの？

751 ：デフォルトの名無しさん：2008/11/17(月) 23:11:22

>>750　
Tortoiseの方は.bzr/.branch/branch.confで
「encoding = エンコーディング」を指定したら
logメニューからの表示は文字化けしなくなった。
diffメニューからの表示は文字化けするようだ。

コマンドラインから起動する場合はbzr qdiff --encoding=ARGで
一回実行すればエンコーディングのオプションはbranch.confに記録される。

752 ：デフォルトの名無しさん：2008/11/17(月) 23:15:17

>>741
Gitのマージアルゴリズムはhgやbzrよりも劣るんじゃなかったっけ。
最近はそうでもないのかな?

753 ：デフォルトの名無しさん：2008/11/18(火) 02:47:52

Mercurialで、不要になったbranchを閉じるって、今のところ実装されてないんだね。
↓一応、対策は提案されてるけど。
http://www.selenic.com/mercurial/wiki/index.cgi/PruningDeadBranches

開発チーム内に余計なbranchを作る奴が居ても、ずっと放置か。
hg branchしてない、名無しのheadでも同じ事だよね。

今のところは、リポジトリのcloneによる（概念的）branchの方が整理をつけやすくて
安全って事なのかな。

754 ：デフォルトの名無しさん：2008/11/18(火) 03:01:03

>>748
そう。さくらのレンタルサーバーとか、FTPやsftpが使えれば、サーバーに
bzrをインストールしなくてもクライアントにだけbzrがあれば使えるのが強み。
これに慣れると、gitとかサーバー側にインストールするの面倒。

755 ：デフォルトの名無しさん：2008/11/18(火) 03:06:22

>>750
中身がしっかりしてれば、表面なんてどうにでもなる。
あるひとつの条件で、たまたまsvnが化けずにbzrが化けたからって、
svnの方が良いと考えるのは軽率すぎる。

bzrで化けるときの対策方は>>751が教えてくれたけど、TortoiseBzrで
WinMerge使えるようにはしたいね。今忙しいけど、手の空いたときに
試してみる。

756 ：デフォルトの名無しさん：2008/11/18(火) 03:17:06

>>754
sshfs でマウントしてしまえば git だろうが hg だろうが自由自在だと思うが.

757 ：デフォルトの名無しさん：2008/11/18(火) 03:25:17

Windowsでsshfsとかできないじゃん
sshfsする一手間が面倒じゃん
そもそも、安いレンサバだとssh使えないでFTPだけ使えるとかあるじゃん。

758 ：デフォルトの名無しさん：2008/11/18(火) 06:49:18

>>755
bzrは日本語全く問題ないんではなかったのか？
問題ありありなわけだが。嘘つき。
単一プラットホームで化けるなんて、中身がどうのこうの以前の問題だろ。
いくら、小手先の対策示しても意味ない。

759 ：デフォルトの名無しさん：2008/11/18(火) 11:33:44

>>758
そもそもdiffってのは、二つのファイルのエンコーディングと、ファイル名のエンコーディング、
合計3つのエンコーディングが混ざってるから、「完全」なんてありえないんだよ。

たとえば、コンソールでdiff出力してファイル名が化けるのは、ファイル名をUTF-8で出してるから。
svnで化けないって事は、svnはlocaleやコードページに変換してるんだろうな。
でも、そのdiffで作ったパッチを、メールでLinuxユーザーに送ったらどうなると思う？

「問題ない」といってるのは、「ソ連」みたいな0x5c問題や、環境依存のファイル名エンコーディングを
そのままリポジトリにぶち込んでしまってほかの環境でファイル名が化けたりといった、日本語
ファイル名を扱う上での話をしてるんだよ。

760 ：デフォルトの名無しさん：2008/11/18(火) 15:21:47

それってdiff一般の話じゃないよね。
bzrのdiffの実装がそうなってるってこと？

761 ：デフォルトの名無しさん：2008/11/18(火) 20:01:04

>>760
コンソール上のdiff一般の話だよ。
diffが化けないのは、(1)コンソール、(2)ファイル名、(3)二つの入力ファイルの内容
すべてのエンコーディングが一致したときのみ。
ファイル名に関しては、diffで作ったパッチを送信したりすることを考えるとエンコーディングを
統一するべきで、統一するならUTF-8が妥当。なので、コマンドプロンプトをchcpでUTF-8
モードにするか、 diff | gvim - みたいにテキストエディタで見るしかない。

Linux でも、 diff の出力はリダイレクトでファイルに保存するかパイプで直接エディタで見るのが基本。
Bazaar Plugin の extdiff を使えば、外部の diff プログラムと連携できる。Windowsなら
WinMergeとか使うと吉。

762 ：デフォルトの名無しさん：2008/11/18(火) 20:02:56

>>755
せっかくなので外部コマンドとエイリアスの使い方を書いておきます。
当面はコマンドツールとの併用になるでしょうから。

bzr diffでWinMergeを使いたいならオプションとして--using=WinMergeを指定します。
WinMergeの注意事項としてはmlang.dllによるコードページの検出オプションを
有効にしていないと付けないと文字化けします。

オプションの入力を省略したければbazaar.confファイルを
編集してエイリアスを設定します。
設定ファイルの位置はbzr versionで見つかります。

[ALIASES]
diff=diff --using=WinMerge

763 ：デフォルトの名無しさん：2008/11/18(火) 20:10:06

ちなみに、GUIのdiffプログラムだとテキストエディタと同じで文字コード指定が
簡単にできたり自動認識したりすると良くて、その点 TortoiseBzr の中の qdiff は
機能不足。（これはBazaarの問題ではないが、周辺環境が揃ってない一例）

俺はソースをはじめテキスト類は全部UTF-8で書いてるから qdiff でも全く文字化け
しない。
Windowsも早く日本語の標準マルチバイトエンコーディングをUTF-8にすれば良いのに、
いつまでcp932なんて使ってるんだろう・・・

764 ：デフォルトの名無しさん：2008/11/18(火) 23:43:44

cp932なのはwindowsが悪いけど、
今のbzrだと文字コードのせいですんなり使えないね。

765 ：デフォルトの名無しさん：2008/11/19(水) 01:05:57

Mercurialのレポジトリをhgwebdir.fcgiで公開してるんだけど，これってすごく重くない？
うちのサーバがボロってのもあるかもしれないけど，大きめのファイルを開くと一気に
ロードアベレージが跳ね上がってしまう．
pdfファイルに至っては選択するといつまでたっても応答が返ってこないでCPU食いつぶしてるし．
これってこういうもんなの？

766 ：デフォルトの名無しさん：2008/11/19(水) 01:51:29

>>765
スペック、構成、設定、ロードアベレージは具体的にどのプロセスが、IOとCPUのどちらで
重いのか、hg serve と比べてどれくらい遅いのか。

これくらいまとめてから質問しようぜ。

767 ：765：2008/11/19(水) 10:04:11

>>766

単に愚痴るだけのつもりだったんだけど，そのくらいの情報は出しとかないと
毒にも薬にもならんわな．すまん．

サーバ機のスペックは
CPU: Celeron 2.4GHz （詳しいことは忘れた．4年前くらいのセレロン）
メモリ: 256MB
OS: Ubuntu 8.10

このマシン上でlighttpdからhgwebdir.fcgiを呼び出してる．
hgwebdir.fcgiはHGENCODINGをUTF-8に指定したくらいで，
他は特ににいじってない．
各レポジトリはbz2，gz，zipでのダウンロードを許可していて，
pushにはDigest認証が必要にしてある

で，pdfを開くと応答が返ってこないんだけど，このときCPU使用率が
跳ね上がっていることを確認済みで，IOなどは特に異常な数値は示し
ていない．原因になっているプロセスはwebサーバを走らせているユー
ザの権限で動いている
python /usr/share/hg/cgi-bin/hgwebdir.fcgi

他の形式（テキスト形式のファイルや画像）だと，pdfよりサイズが
大きい場合でも一時的にCPU使用率があがるものの，きちんと表示される．

あと，hg serveだと動作が軽快にはなってるみたいなんだけど，
pdfを開こうとすると上で書いたのと同じような症状になって応答が
返ってこなくなる．

768 ：デフォルトの名無しさん：2008/11/19(水) 10:12:13

>767
知らんけど、内部でPDFをテキスト化するツールとか、Ghostscriptとかを
呼び出そうとしてトラブってるんじゃないの？　Prostscriptの記述がバグって
無限ループしてるとか、展開サイズが大きすぎてメモリ不足になってるとか。

769 ：デフォルトの名無しさん：2008/11/19(水) 12:10:57

TortoiseHg 0.5での質問があります。

・日本語ログがupdate revisionで化けるので、事実上日本語ログが使えなくない？
・GUIで hg mv する方法はないのでしょうか？
・pushした日本語ファイル名がWindows以外の環境で化ける、というのは本当でしょうか？

770 ：766：2008/11/19(水) 12:21:38

>>767
ん、メモリが少なめだから、全体的にロードアベレージが高いのは
リポジトリがキャッシュからすぐに消えちゃってる可能性がある。
pdfに関してはIOが低いならメモリの問題じゃないんだけど、Mercurialは「pdfだけ」
という処理はしてない。変なプラグインは入れてないよね？

ということで、こっからエスパー。
pdfって、ブラウザプラグインで、ブラウザの画面内に表示してない？
その場合、HTTPクライアントはブラウザじゃなくてプラグインになってるから、
それが分割ダウンロードとかしようとして負荷をかけてる可能性がある。

Adobe Readerのブラウザプラグインを無効にして、ブラウザが
「テンポラリファイルに保存→スタンドアロンのAdobe Reader 起動」
するようにしてみて。

あと、hg serveで軽くなるなら、fcgiの設定が良くない（メモリ食い）という可能性がある。
fcgi使ったこと無いんだけど、スレッド数やプロセス数を減らせない？
lighttpd も同時接続数を3くらいに減らしてみて。

771 ：デフォルトの名無しさん：2008/11/19(水) 12:31:35

>>769
最後の問題、ファイル名エンコーディングをロケールから判別して、リポジトリに
入れる前にUnicodeへデコードするパッチを日本人が本家MLに送ったんだけど、
「ファイル名はファイルの内容と同じでバイナリ弄らない」とか言われてrejectされた。
なので、今は win32mbcs という拡張で対応しないといけない。一人でも対応してない
ヤツがpushしたら、そのリポジトリはcp932ファイル名で汚される。

ただし、これはコンソールのエンコーディングがUTF-8じゃない場合の話で、
TortoiseHgだと最初からUnicodeでファイル名を使ってるかもしれない。
俺は TortoiseHg 使ってないんだけど、コンソールとTortoiseで日本語ファイル名を
やり取りしてみたら？

772 ：769：2008/11/19(水) 12:36:20

> ・pushした日本語ファイル名がWindows以外の環境で化ける、というのは本当でしょうか？

そもそも、Mercurialでは日本語ファイル名がコミットできないようです。

TortoiseHgでは、コミットウインドウでファイルを追加してもcommitボタンが押せず、
全選択チェックボックスを押すとcommitボタンが押せるのですが、
正常コミット時のように閉じてくれず、hg stで確認しても変化なしでした。

コマンドラインのhgでは、

　> hg ci -A -m "initial commit from command line"
　adding ・が怖い、・の・フトSJIS.txt
　removing ・が怖い、・の・フトSJIS.txt
　・が怖い、・の・フトSJIS.txt not tracked!
　・が怖い、・の・フトSJIS.txt does not exist!
　nothing changed
というように言われ、hg stで確認しましても変化ありません。

実はWindowsでのhgは日本語ファイル名に対応してなかったのですね・・・。
TortoiseHg 0.5と付属のコマンドラインのhgで確認しました。

ファイル名：表が怖い、噂のソフトSJIS.txt
中身は適当な感動コピペをSJISで保存です。

773 ：769：2008/11/19(水) 12:40:13

>>771
ああ、わかりました。
標準でSubversionのようにUnicodeへのデコードなどはやってないわけですか。
で、ロケール（日本語WindowsだとSJIS？）で入ってしまう、と
（そもそも入りすらしなかったけどｗ）

ファイル名とかログのエンコード周りは基本的なことだと思うのになあ。
OSSで使うならなお更なのに・・・

774 ：デフォルトの名無しさん：2008/11/19(水) 12:46:20

>>773
入りすらしないのは、0x5c問題だと思うよ。
0x5cが入ってないファイル名だと、コミットはできるけど、そのままリポジトリに入っちゃう。
(から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)

そもそも「ファイル名はバイト列として変更せずに扱う」というポリシーが間違ってると思うけど、
外国人には伝えにくいからねぇ。gitは最初からWindowsなんて気にしてないし。

Python3.0になると、文字列＝unicodeになるから、「ファイル名のバイト列」自体消滅する。
MercurialもPython3.0対応する時点で嫌でもポリシーを修正するはず。
その前にBazaarに乗り換えたほうが幸せな気もする。

775 ：765：2008/11/19(水) 13:03:46

>>768
Mercurialのレポジトリブラウザってpdfをテキスト化して表示するの？
コード眺めた感じそれっぽい部分は見当たらなかったけど．

>>770

> pdfに関してはIOが低いならメモリの問題じゃないんだけど、Mercurialは「pdfだけ」
> という処理はしてない。変なプラグインは入れてないよね？

そうなんだよね．なんでpdfに限ってこんなことになるのかがよくわかんない．
プラグインもなにも入れてないです．

> Adobe Readerのブラウザプラグインを無効にして、ブラウザが
> 「テンポラリファイルに保存→スタンドアロンのAdobe Reader 起動」
> するようにしてみて。

やってみたけど，症状はかわらずです．
というか，テキスト表示できないタイプのファイルってチェンジセットから
選択すると，最初に"これはバイナリファイルですよ"みたいなページに
遷移するよね？そのページのrawの項目を選択するとダウンロードが始まる，
みたいな．
pdfの場合，チェンジセットから選択したあとの最初の遷移の段階でとまって
しまうので，そのあたりは関係ないような気もする．

> あと、hg serveで軽くなるなら、fcgiの設定が良くない（メモリ食い）という可能性がある。
> fcgi使ったこと無いんだけど、スレッド数やプロセス数を減らせない？
> lighttpd も同時接続数を3くらいに減らしてみて。

いちおうlighttpd側でmaxprocsを3にはしてあるんですけど，だめですね．

776 ：769：2008/11/19(水) 13:05:29

>>774
> (から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)
いけますタ！
hg と TortoiseHgの両方でいけることを確認しました。
どうやらすごいFAQみたいですね。

それにしても、TortoiseHgがコミットログやらファイル名やら化けまくりで実用に耐えられないなあ・・・
プログラマはそんなでもないけど、デザイナとか複数人で使う時に、
英語ファイル名、英語ログ強制はまず使ってもらえないわｗ

バージョン管理ソフトとかこういう環境的な物の導入には、
手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。

> その前にBazaarに乗り換えたほうが幸せな気もする。
そちらを検討してみます。

いろいろ教えてくれてありがとう。

777 ：769：2008/11/19(水) 13:06:19

> バージョン管理ソフトとかこういう環境的な物の導入には、
> 手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。

バージョン管理ソフトとかこういう環境的な物の導入には、
ソフトウェアの使い勝手よりも、むしろ
手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。

778 ：766：2008/11/19(水) 14:24:59

>>775
あらら、エスパー失敗か。

じゃぁ、その pdf ファイルの先頭 4096 バイト内に 0 というバイトが存在しないと予測。
Mercurialは先頭4096バイトの中に 0 が有るかどうかでバイナリとテキストを判別しているから、
テキストだと思って頑張って表示しようとしている可能性がある。

779 ：デフォルトの名無しさん：2008/11/19(水) 14:33:54

>>774
> (から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)

環境変数 HGENCODING に cp932 を設定するのとでは何か違いある？

780 ：765：2008/11/19(水) 17:35:50

>>778

それであたりっぽい．util.binaryが問題の部分だね．
開発ブランチだとファイル全体で0というバイトの有無を判定してるので，
そっちを使ってみることにするよ．

今サーバが落ちてるので，結果がわかり次第また書き込むわ．

781 ：デフォルトの名無しさん：2008/11/19(水) 17:57:13

Mercurialは、どんなにTortoiseの完成度が高くなっても
デザイナーには使えない。概念的な部分の複雑度が高すぎる、
ってのが俺の印象だな。
プログラマーさえ、チームの2割もまともに理解できる奴いないと思う。

782 ：デフォルトの名無しさん：2008/11/19(水) 19:14:28

PDFってテキストファイルの中に一部バイナリ埋まってるような構造だからなぁ

783 ：765：2008/11/19(水) 20:44:14

765です。>>766さんの指摘で問題解決したので報告します。

問題の原因はファイルがバイナリかテキストかを判定するutil.binaryが、ファイルの先頭4096バイ
ト中に0というバイトがあるかどうかをチェックしていたことでした。

なので、この問題はutil.binaryを書き換えることで解決可能です。最初は開発版を使おうかと思って
いたけど、書き換えのみでとりあえず解決できたのでそうしました。ちなみに、バージョン1.0.1
のものを書き換えました。

書き換え自体は簡単なのでここには書かないけど、わからなければ開発版のコードを見れば大丈夫。

以上報告でした。付き合ってくれた方々ありがとう。

784 ：デフォルトの名無しさん：2008/11/19(水) 21:04:22

git format-patch でできたパッチを適用するのは git am しかないんでしょうか。
メールボックスとかシランので、単に git format-patch でできたパッチを適用したいだけなんですけど。

785 ：デフォルトの名無しさん：2008/11/19(水) 21:17:51

>>784
git am 0001-patch-name.patch
でいけました。メールボックスじゃなくてもいけますね。すんません。

786 ：デフォルトの名無しさん：2008/11/19(水) 21:51:03

hgのwin32mbcs拡張は前見たときは単に0x5c問題だけ回避してるように見えたんだけど
リポジトリに記録されるエンコーディングをユニコードにしてるって本当？

787 ：デフォルトの名無しさん：2008/11/20(木) 01:09:34

>781
基本的に理解力の低い人は、理解できない部分は無視してくれるので(例外は居るが)
まずはバックアップ支援ツールとして広め、ちょっとずつ高度化してくのが吉かと。

788 ：デフォルトの名無しさん：2008/11/20(木) 14:48:10

＞概念的な部分の複雑度が高すぎる

ってのを読んだ限りだと、こいつは自分で使ったことが無いんだろうな

789 ：デフォルトの名無しさん：2008/11/20(木) 19:27:17

>788
いや、使ってみた感想だよ。俺が主に使ったのはLinux版のコマンドラインでだが。
他のメンバーは、より簡単なSubversion + TortoiseSVNでさえ、何度も繰り返し教えて
やっと使えるようになった状態だし、デザイナーが触るファイルにはロック機構が要ると思う。

プログラマでさえ、衝突時のマージがうまく出来ない奴も居るし、別branchの変更点を
trunkに取り込む為のマージ操作が出来る奴も限られてる。

で、この現状を見た時、より難解なMercurialを無事に導入出来るとは思えなかった。

790 ：デフォルトの名無しさん：2008/11/20(木) 19:34:37

svnの操作がどうこうよりもSCMについての根本的な理解が欠けてるだけなのでわ

791 ：766：2008/11/20(木) 21:03:38

>>789
Subversion から

792 ：デフォルトの名無しさん：2008/11/20(木) 23:18:43

>789
だからまずはバックアップツールとして使って貰えと。
いきなりコンフリクトの解決方法云々は、性急過ぎる。
SCMの歴史を追うように、RCS的な使い方から順に、
少しづつ教えていった方が理解は早いぞ。

というか、いきなり高度な事を教えると基礎がおろそかに…

793 ：デフォルトの名無しさん：2008/11/21(金) 08:40:27

>>789
俺もチーム内で広めようと思っているんだけど、
こんなの使えねー、っていうのをなるべく避けるいい方法ないかね。

まずは、
バックアップツール＝個人で使ってもらう
↓
？
↓

補完キボン

794 ：デフォルトの名無しさん：2008/11/21(金) 11:08:45

バックアップツール＝個人で使ってもらう
↓
毎日終業後に、SCMボランティアとして >793 が各メンバーのワーキングディレクトリを
チェックして回り、trunkとマージしてあげる
↓
「>793 っていい人だよね」

795 ：デフォルトの名無しさん：2008/11/21(金) 11:30:55

1年くらい前にSubversionを使わせるようになったけど
使わせるにあたって最近は分散型が流行ってて
こんな事が出来るようになると言っておいた

慣れてくると、こんな事が出来るようになると便利なのにって
思うようになるから、予めそう言う知識の断片だけを
頭に入れて貰ってから使わせてる

で、最近は分散型にも徐々に興味を持ってくれるようになった

問題は俺がSVKしか使えないことなんだけど

796 ：デフォルトの名無しさん：2008/11/21(金) 15:17:05

svnのコマンドを拡張して分散型として使わせてくれたらうれしいんだけどね。
そもそもコンセプトが違うし無理か。

797 ：デフォルトの名無しさん：2008/11/21(金) 15:45:44

>>796
それが svk
ただし、サイズ的にも速度的にも効率悪い。

798 ：デフォルトの名無しさん：2008/11/21(金) 15:47:16

あ、あと、Bazaarリポジトリを svn:// プロトコルで見せようというプロジェクトもある。
まともに開発されてるのかは知らないけど。

799 ：デフォルトの名無しさん：2008/11/21(金) 16:30:50

つ git-svn
google code projectでもgit使える。

Google Open Source Blog: Develop with Git on a Google Code Project
http://google-opensource.blogspot.com/2008/05/develop-with-git-on-google-code-project.html

800 ：デフォルトの名無しさん：2008/11/21(金) 16:54:15

gitはコマンド違いすぎるだろjk

801 ：デフォルトの名無しさん：2008/11/21(金) 21:39:31

>793
(1)バックアップツールとして広める
(2)ある程度慣れてきたら、ブランチを切ったりマージする方法を教える。
　他人の持ってるファイルを修正する必要が出てきた時や、
　複数のバージョンを管理しなきゃならなくなった時を見計らって教えると良いかも。
(3)頃合を見計らって集中管理を始めるか、分散型だったらpush/pull等を教える。

802 ：デフォルトの名無しさん：2008/11/21(金) 23:47:12

・diffツールとして広める
のほうが良くね？

803 ：デフォルトの名無しさん：2008/11/22(土) 02:21:41

俺はファイルサーバ(レポジトリ)に自動でアップロード・ダウンロードを
してくれうソフトとして広めた。
これだと考え方が集中型に固定されてしまう気がしないでもないが……。

804 ：デフォルトの名無しさん：2008/11/22(土) 05:36:36

http://anond.hatelabo.jp/20081120002535
こんな事態を避ける為にもバージョン管理システムを使いましょう

805 ：デフォルトの名無しさん：2008/11/22(土) 05:44:27

SubversionのVが大文字・・・

806 ：デフォルトの名無しさん：2008/11/22(土) 07:42:04

修正履歴というと ChangeLog のこと？

807 ：デフォルトの名無しさん：2008/11/22(土) 08:29:45

>>805
確かに「大恥かくでしょうがｗｗ」って書いといて SubVersion はないよな。

>>806
ChangeLog をソースのどこかに入れてるところもあるけど、>>804 のリンク
先が言ってるのは

// int i = 10; // DEL: 2008/11/10: Bug 1234 by ○○
int i = 11; // CHG: 2008/11/10: Bug 1234 by ○○
float f = 1.23; // INS: 2008/11/09: Bug 1230 by △△

みたいな奴だと思う。

808 ：デフォルトの名無しさん：2008/11/22(土) 08:48:06

// add 2008.11.22 nanashi-default
hoge.huga();
// add end 2008.11.22 nanashi-default

前の会社これだったな。CVS入れていても。

809 ：デフォルトの名無しさん：2008/11/22(土) 09:04:03

>>808
うちもそうだった……

つかコーダの人はCVS使えない
（結合試験完のソースを管理者に渡してコミットしてもらう）
辺りが間違いの元だったんじゃないかと……

810 ：デフォルトの名無しさん：2008/11/22(土) 09:07:12

>>808
うちもSubversion使ってるのにもかかわらず、そうする奴がいる。
本来のソースが見づらくなるんだよな。

811 ：デフォルトの名無しさん：2008/11/22(土) 09:15:18

> （結合試験完のソースを管理者に渡してコミットしてもらう）

刑務所みたいなふいんきを想像した

812 ：デフォルトの名無しさん：2008/11/22(土) 13:44:43

>>810
いるいるwww 俺はコーディング規約で明確に禁止した。

813 ：デフォルトの名無しさん：2008/11/22(土) 19:40:49

そういう奴らはDiffの使い方がわかってないんだよ。
TortoiseSVNやRapid入れて過去ログとの比較を教えてやったら二度としないと思うけどな。

814 ：デフォルトの名無しさん：2008/11/22(土) 19:51:07

コミット時にフックを掛けて弾くのも効果ある

815 ：デフォルトの名無しさん：2008/11/22(土) 20:27:51

>813
diffの使い方が分かってないと言うよりは、blame/annotateの使い方が分かってないんだろ。

816 ：デフォルトの名無しさん：2008/11/22(土) 20:36:06

blameはよくわからん

817 ：デフォルトの名無しさん：2008/11/22(土) 20:41:17

TortoiseSVNなら、blameの結果が専用ビューワーで超見やすい。

818 ：デフォルトの名無しさん：2008/11/22(土) 22:07:02

ところで、

いい加減TortoiseSVNのアップデートは自動でできるようにならんかね？
アップデートのたびにホームページ行ってダウンロードして上書きインストールしてから再起動･･･って
いちいち面倒だっつうに。

819 ：デフォルトの名無しさん：2008/11/22(土) 22:13:53

アップデートのたびにホームページ行ってダウンロードして上書きインストールしてから再起動するプログラムを作る

820 ：デフォルトの名無しさん：2008/11/22(土) 22:26:38

それこそsvn updateで行えるべきだ

821 ：デフォルトの名無しさん：2008/11/23(日) 01:01:08

>>820
もまえ天才

822 ：デフォルトの名無しさん：2008/11/23(日) 07:39:40

diffはちょっと馬鹿なとこがあって、メソッド１つ追加したら
次のメソッドの説明コメント１行目まで差があることになったりするよな。
確かにそういう解釈にならんことも無いんだが、
あれ、どうにかならんかなあ。

}
//------------
+//func2
+//------------
+void func2 () {
+ ...
+}
+
+//------------
//func3

823 ：デフォルトの名無しさん：2008/11/23(日) 07:57:15

異なる行を取る仕様上、そういう動作にならざるを得ないのでは
どうしても気になるならコメント一行目が違うように記述するとか…？

// func2 --------
// 説明
// -------------

// func3 --------
うーん…

824 ：デフォルトの名無しさん：2008/11/23(日) 09:33:02

diff はコメントとかを意識してるわけじゃないからなあ。
言語仕様を意識した diff を作るか、>>822 のバカな認識を
変えるしかないと思う。

825 ：デフォルトの名無しさん：2008/11/23(日) 09:37:17

>>824
言ってることはそれなりに正しいのに、たったの三文字で台無しだ。

826 ：デフォルトの名無しさん：2008/11/23(日) 10:24:16

コメントを関数の中で定義すれば？
void func2 () {
//------------
//func2
//------------
...
}

827 ：デフォルトの名無しさん：2008/11/23(日) 12:19:43

ここでpythonのコーディング規約が優れていることが判るわけですね。

828 ：デフォルトの名無しさん：2008/11/23(日) 12:59:52

>>825
三文字？もしかして「バカな」に逆切れ？

>>826
ソースの見辛さと diff の見辛さの二択なら、ソースの方を優先すべきだと思うが。

829 ：デフォルトの名無しさん：2008/11/23(日) 14:29:28

ずらすだけならむずかしくない

830 ：デフォルトの名無しさん：2008/11/23(日) 22:51:43

git add したファイルを取り消すにはどうしたらいいですか。
＃なんかgitのマニュアルはわかりずらい。

831 ：デフォルトの名無しさん：2008/11/23(日) 22:52:25

>gitのマニュアルはわかりずらい
禿同

832 ：デフォルトの名無しさん：2008/11/23(日) 23:00:20

ちょっとした煽りに過敏に反応する世代がこのスレに居るとはな

833 ：デフォルトの名無しさん：2008/11/24(月) 04:25:13

TortoiseHg使って、公開鍵認証が必要なssh経由でcloneしようとしたら、結構面倒だった。

インスコそのままだとパスワード方式しかダメで、ホームディレクトリのmercurial.iniを
書き換える必要がある。Program Files以下の同名ファイルを見たら、cygwin sshの
設定がコメントアウトされてたんで、それをコピペしたらこれが罠で、秘密鍵のパスフレーズを
入力不可能な標準入力で入力待ちしてしまって、アプリが固まる。

諦めて標準のTortoisePlink.exeを使う事にして、mercurial.iniで「-i 秘密鍵へのパス」
オプションを追加すると、やっとGUIダイアログでパスフレーズを聞いてくれるようになった。
もっともその前に、puttyを落としてきてOpenSSHの秘密鍵をputty形式に変換するという
さらにめんどくさい作業が必要。以上、作業メモ。

834 ：デフォルトの名無しさん：2008/11/24(月) 07:07:23

>>832
>ちょっとした煽りに過敏に反応する世代がこのスレに居るとはな
そのまんま832のことじゃないか

835 ：デフォルトの名無しさん：2008/11/24(月) 08:33:17

>>833
たぶん、普段から putty と pageant なり、mingw の ssh なりを使っている人には
面倒じゃないんだろうな。

putty の設定で、秘密鍵ファイルの設定がレジストリに書かれていたら、
-i オプションが無くても秘密鍵は自動で選ばれるし、 pageant を使っていると
秘密鍵のパスフレーズ入力も無い。

Bazaar も pageant あると自動で利用してくれるから、 pageant お勧め。

836 ：デフォルトの名無しさん：2008/11/24(月) 12:34:14

>>833
前にBitBucketにコミットしたときは、pageant立ち上げておくだけで行けたけど

837 ：デフォルトの名無しさん：2008/11/24(月) 19:02:37

一番いいのはどれなの？

838 ：デフォルトの名無しさん：2008/11/24(月) 20:17:18

linuxerならgit一択
*NIXerならhgかbzr

839 ：デフォルトの名無しさん：2008/11/24(月) 20:28:55

darcs使いとしては，最近のdarcsのガラパゴスぶりに泣けてくる

840 ：デフォルトの名無しさん：2008/11/24(月) 21:06:19

でも hackage の都合上選択肢は darcs しかないという

841 ：デフォルトの名無しさん：2008/11/24(月) 21:33:06

Linus儲ならgit、Shuttleworth儲ならbzr、それ以外ならhgでおk。

842 ：デフォルトの名無しさん：2008/11/24(月) 21:43:48

subversionより、いいのってあるの？

843 ：デフォルトの名無しさん：2008/11/24(月) 22:46:29

とりあえず hg の mq は最高ってことで。

844 ：デフォルトの名無しさん：2008/11/24(月) 23:02:42

>>843
rebaseで良くね?

845 ：デフォルトの名無しさん：2008/11/24(月) 23:14:16

よく分からんけど、Mercurialのrebaseって、gitの機能をパクったの？
mozilla.orgと関係有るっぽい？

846 ：デフォルトの名無しさん：2008/11/24(月) 23:16:06

rebaseってsvn由来じゃ?

847 ：デフォルトの名無しさん：2008/11/25(火) 22:40:01

ポリシーに合ってる機能ならどんどんパクるべきだろ。

848 ：デフォルトの名無しさん：2008/11/26(水) 01:09:14

Mercurial で 0x5c で終わるディレクトリがあるとおかしくなるのは
うちだけ?

hg init .
mkdir 管理表
hg status
abort: 指定されたファイルが見つかりません。: D:\HGTEST\test\.\管理表\管理表

win32mbcs を読み込ませても同じ。

849 ：デフォルトの名無しさん：2008/11/26(水) 01:14:46

NetBeansでつかってるけど、マルチバイトのファイル名で
おかしくなるからそれは管理しないようにしないとだめ

コミットログ等は問題ないけどね

しかし表でおかしくなるとかあいかわらず世界は
マルチバイト圏のことはまったく考慮されてないんだなぁとおもた

十数年たってもこれだから100年後もかわってないかも

850 ：デフォルトの名無しさん：2008/11/26(水) 01:16:58

>>848
Cygwinだったら、cygwin1.dllのせい。UTF-8 cygwin 使っとけ。
それ以外だったらわからん。

851 ：デフォルトの名無しさん：2008/11/26(水) 01:18:23

日本語ファイル名使うなら bzr か svn にしとけって。
hg や git はUnicodeファイル名じゃないんだから。

852 ：デフォルトの名無しさん：2008/11/26(水) 01:30:23

>>849
10年どころか、PCで日本語扱うようになって四半世紀くらい経ってますぜ。
とは言え、Unicode/UTF-8の普及でほんの少しだけマシになってます。
それ以上に多種多様な問題も連れてきたけど。

>>771に書かれてる「ファイル名はファイルの内容と同じでバイナリ弄らない」
って、判断したやつにUnicode正規化の問題とか突き付けてやりたい……。

853 ：デフォルトの名無しさん：2008/11/26(水) 07:30:44

>>852
というかユニコード正規化とか言葉もしらないんじゃないかと。
規約や規格にわりと無頓着なプログラマって多いと思う

854 ：デフォルトの名無しさん：2008/11/26(水) 08:35:58

統一性がないのにユニなコードとはこれいかに

855 ：デフォルトの名無しさん：2008/11/26(水) 12:42:46

>>854
ほんとだよ

856 ：デフォルトの名無しさん：2008/11/26(水) 16:59:46

環境: WindowsServer2008 cygwinなし

TortoiseHGを試していて分らないことがあったので質問です。

適当なディレクトリで右クリでリポジトリを作成したり、
そのリポジトリに適当なファイルを置いてaddして登録することはできるのですが
HG commitしようとすると、ウィンドウが一瞬だけ表示されてすぐ消えてしまいます。
どうやらコミットが強制的にキ?%

857 ：デフォルトの名無しさん：2008/11/26(水) 17:01:25

すいません、ブラウザの不調でレスが後半潰れてしまったようです

環境: WindowsServer2008 cygwinなし

TortoiseHGを試していて分らないことがあったので質問です。

適当なディレクトリで右クリでリポジトリを作成したり、
そのリポジトリに適当なファイルを置いてaddして登録することはできるのですが
HG commitしようとすると、ウィンドウが一瞬だけ表示されてすぐ消えてしまいます。
どうやらコミットが強制的にキャンセル?されているようで、コミットされている様子がありません。

ネットで調べた限りでは、HG commitメニューを実行すると
ログを書き残したりするためのダイアログが出てくるという事なのですが・・・

何を調査してどんな手を打てばいいかさっぱり検討も付かないので
どなたか対処を思いついた人がいたら教えて下さい

858 ：デフォルトの名無しさん：2008/11/26(水) 19:13:07

>>857
操作しようとしてるフォルダのパスに、日本語が含まれてないか？
Hg解説してる場所でTortoiseHgはパス、ログもほとんど日本語が使えないと書いてあった気がする。
もっとも、その解説0.30あたりの時だったから最新版ではわからんけど。

859 ：デフォルトの名無しさん：2008/11/26(水) 21:14:32

つーか日本語ファイル名なんてありえないだろJK

860 ：デフォルトの名無しさん：2008/11/26(水) 21:28:50

パスセパレータに/を使わないシステムがクソなだけ

861 ：デフォルトの名無しさん：2008/11/26(水) 22:25:22

win32mbcs エクステンションを入れてないとか

862 ：デフォルトの名無しさん：2008/11/26(水) 23:08:05

>>859
世の中理想だけじゃ回らんだろ。
仕事で日本語パスが使ってある既存プロジェクトに放りこまれたときどうすんだ。

863 ：デフォルトの名無しさん：2008/11/26(水) 23:20:47

ソースはまだありえないと思うが、ドキュメントとかなら普通に
使ってるからなぁ > 日本語ファイル名

864 ：デフォルトの名無しさん：2008/11/26(水) 23:45:35

>>863
某社の某製品が自動生成するソース(Java)は、ファイル名にもクラス名にも変数名にも日本語で吐かれるよ!!

865 ：デフォルトの名無しさん：2008/11/26(水) 23:55:01

>>864
悪夢だ

866 ：デフォルトの名無しさん：2008/11/27(木) 01:19:18

>>864
変数名とかメソッド名はファイルシステムに依存してないし、Javaのシステム上問題はない
だがクラス名につかっちまうとファイルシステム依存が出てきて大変なことになる

867 ：デフォルトの名無しさん：2008/11/27(木) 11:17:11

俺は個人的なプログラムではクラス名も変数名もばんばん日本語使うけどな。
いざというときでもEclipseやら使えばリネームは一発だし、そんなに困ると思えん。
プログラムが日本語チックに書けてコメントいらずだし。

868 ：デフォルトの名無しさん：2008/11/27(木) 12:08:49

識別子が日本語になるだけでコメントがいらなくなるものは
命名が悪いからコメント必要になってるだけだろｗ

869 ：デフォルトの名無しさん：2008/11/27(木) 12:41:11

変数名とか関数名を日本語にするやつの気が知れない

870 ：デフォルトの名無しさん：2008/11/27(木) 12:48:44

ちゅうか、ことコンピュータに関しては、英語圏の奴らがマジうらまやしい。

871 ：デフォルトの名無しさん：2008/11/27(木) 12:54:53

昔、某所で使ってた開発言語は日本語だったけど
手続き全て日本語ってのはマジで辛かったよ
廃止されてホッとした

872 ：デフォルトの名無しさん：2008/11/27(木) 13:04:47

ソースから仕様書も作れるって言うアレだな・・・
おやじどもには好評だったな

873 ：デフォルトの名無しさん：2008/11/27(木) 14:10:54

formから生成するときは母国語使える方が楽だとは思うぞ

874 ：デフォルトの名無しさん：2008/11/27(木) 15:46:13

漢字が使えたほうがいい場面は確かにある。
「部材別商品管理棚」を表すクラスを英語名にすると、わけわからんなる。
業務に強く依存する名前は別に日本語のままでいいよなと思う。

875 ：デフォルトの名無しさん：2008/11/27(木) 16:02:08

それだけ見れば、業務に強く依存するようなコードは糞だという感想しか湧かない

876 ：デフォルトの名無しさん：2008/11/27(木) 20:35:57

で、なんで日本語だめなの？

877 ：デフォルトの名無しさん：2008/11/27(木) 20:47:04

一度、全部日本語にしてソースを上から順に眺めていって見ろよ
日本語ってのは曖昧なんだ

878 ：デフォルトの名無しさん：2008/11/27(木) 21:08:45

>>877
曖昧の意味知ってるか？

879 ：デフォルトの名無しさん：2008/11/27(木) 21:20:26

>>875
学生乙

880 ：デフォルトの名無しさん：2008/11/27(木) 21:26:54

>>876
文字コードで面倒が起きることがあるから。

881 ：デフォルトの名無しさん：2008/11/27(木) 21:44:00

DBのカラム名が日本語なのに変数はダメだというのはようわからん考え方だな
アルファベットのカラム名でもExcelの日本語対応表見ながらじゃないとカラム名がわからないほうがよっぽどまずい

けど、そういうところは多いよね

882 ：デフォルトの名無しさん：2008/11/27(木) 21:44:52

DBのカラム名に日本語OKって正気の沙汰じゃございません

883 ：デフォルトの名無しさん：2008/11/27(木) 21:46:23

狂気の沙汰ほど面白い…！

884 ：デフォルトの名無しさん：2008/11/27(木) 22:01:23

倍pushだ

885 ：デフォルトの名無しさん：2008/11/27(木) 22:46:27

>>882
そのかわりExcel方眼紙に日本語名って項目がある笑える環境ではないかね？

886 ：デフォルトの名無しさん：2008/11/27(木) 22:49:20

物理名論理名ってDB設計では普通だろ。

887 ：デフォルトの名無しさん：2008/11/27(木) 23:08:09

ならコードの変数名も対照表作ったら？

888 ：デフォルトの名無しさん：2008/11/27(木) 23:30:03

>>886
単に英語と日本語名だけで、物理とか論理なんて関係ないじゃん。

889 ：デフォルトの名無しさん：2008/11/28(金) 01:02:44

論理名を日本語で付けて、物理名はアルファベットにしとくって話もわからんのか、クズ

890 ：デフォルトの名無しさん：2008/11/28(金) 01:26:31

>>882-883
新手法！アカギ開発ｗ

>>889
888はお察し。多分DBまともに触ったことが無いとか
そういうヤツなんだろ。

891 ：デフォルトの名無しさん：2008/11/28(金) 01:39:15

ソースコードの日本語の話はどうでもいいから
VCSの日本語の話をしてくれよ。

892 ：デフォルトの名無しさん：2008/11/28(金) 01:41:31

VCSが物理名で、SCMが論理名？

893 ：デフォルトの名無しさん：2008/11/28(金) 02:08:00

>>891
ファイル名とコミットログはプラットフォームのエンコーディングに寄らず一律UTF-8かつNFCあたりで正規化、というのが落とし所だと思うんだな。
ファイルには、Content-Type/charsetを属性として付けとく?

894 ：デフォルトの名無しさん：2008/11/28(金) 03:54:15

ttp://github.comメンテナンス中なんだけど、
すまんがおすすめのビデオでも見ててくれ、ってことで、YouTube見させられた。
なんかgithubの中の人は2chみたいなノリでおもしれーｗ

895 ：デフォルトの名無しさん：2008/11/28(金) 04:19:11

消されてんじゃねーかｗ

896 ：デフォルトの名無しさん：2008/11/28(金) 05:35:41

>>895
あれ？　ホントだｗ
さっきまで見れてたんだけどなｗ

なんかオススメごと削除されたっぽいが…勝手に使うなって話だとしたらケツの穴小せえなぁ

897 ：896：2008/11/28(金) 05:41:39

連投スマン
候補からランダムで表示されるようになってて、いくつか消されてるのもある、ってだけだった。

898 ：デフォルトの名無しさん：2008/11/29(土) 20:38:34

>893
結局、Subversionがお手本って事か。

899 ：デフォルトの名無しさん：2008/11/30(日) 14:51:36

別にいいんじゃないの？
svnは今のところもっとも成熟したVCSだし、
そもそもsvnとgit,hgその他の違いなんて分散型かそうじゃないかだけだろ。

それはとにかく、今Mercurialを試してるんだがリポジトリを公開するのにcgi使う必要があったり、
ブラウザ上から日本語ファイルが見えなかったり、
リポジトリそのものに設定ファイルを書かなければいかんかったりと意外とめんどいな。
Gitもリポジトリをウェブへ公開するときの手間は似たようなもの？

900 ：デフォルトの名無しさん：2008/11/30(日) 15:08:30

>>899
bazaar使えばいいじゃん。楽だよ。

901 ：899：2008/11/30(日) 15:24:22

>>900
今windowsとlinux両方で開発してるんだけど、
文字コードのサポートとか、windows上のパフォーマンスとかどう？

902 ：デフォルトの名無しさん：2008/11/30(日) 15:38:14

>>901
>文字コードのサポート
>>735
>windows上のパフォーマンス
悪くはない

903 ：デフォルトの名無しさん：2008/11/30(日) 15:41:10

パフォーマンスにこだわる奴結構いるみたいだけど、具体的に何のパフォーマンスを求めてるんだ？

904 ：899：2008/11/30(日) 15:43:52

>>902
サンクス。このスレ常駐してたんだがgitとhgしか読んでなかった。

wikipedia見るとsvnやcvsのコマンドがそのまま使えるとか、
他のリポジトリとの互換性が最強とか結構よさげ。
一度mercurialからの乗り換え検討してみるわ。ﾉｼ

905 ：899：2008/11/30(日) 15:45:52

>>903
具体的にはweb越しでの転送速度だけど、まあそういわれてみればたいして重要じゃないな。
むしろ安定性や汎用性の方が優先順位が高い。

906 ：デフォルトの名無しさん：2008/11/30(日) 15:55:22

>>899
bzrならhttpでアクセスできるところにファイルをアップロードするだけで
ローカルから bzr coもしくはbzr branchをすぐ試せるよ。

gitの方はリポジトリのホストサーバーにインストールする必要があるみたい。
http経由での git リポジトリのエクスポート
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#exporting-via-http

907 ：デフォルトの名無しさん：2008/11/30(日) 16:48:48

>>906
> gitの方はリポジトリのホストサーバーにインストールする必要があるみたい。
しなくてもできるよ。

908 ：デフォルトの名無しさん：2008/11/30(日) 17:45:44

>>899
cgiで済むなら、むしろ楽だと思うけど。

909 ：デフォルトの名無しさん：2008/11/30(日) 17:54:14

>>907 親切な人、ありがと。できた。

git clone test.git test2.git
touch test2.git/git-daemon-export-ok
cd test2.git
git --bare update-server-info

# test2.gitをサーバーにアップロードした後で
cd ../
git clone http://example.com/test2.git test3.git

910 ：デフォルトの名無しさん：2008/11/30(日) 17:56:38

>>909 訂正。オプション忘れてた。
git clone --bare test.git test2.git

911 ：デフォルトの名無しさん：2008/11/30(日) 18:39:16

つまり面倒なのはhgのみ・・・

912 ：デフォルトの名無しさん：2008/11/30(日) 18:40:55

>>899
> それはとにかく、今Mercurialを試してるんだがリポジトリを公開するのに
> cgi使う必要があったり、
俺は hg serve 上げて Apache の mod_proxy で転送してる。

>ブラウザ上から日本語ファイルが見えなかったり、
HGENCODING=utf-8 にするといいよ。

>>906
>bzrならhttpでアクセスできるところにファイルをアップロードするだけで
>ローカルから bzr coもしくはbzr branchをすぐ試せるよ。
これは Mercurial でも同じことができる。

913 ：906じゃないけど：2008/11/30(日) 18:45:37

>>912
bzr push ftp://...
bzr branch http://...
でおkって話では?
あとhgってremoteなcheckout (非clone)できたっけか?

914 ：デフォルトの名無しさん：2008/11/30(日) 20:15:20

いいんだよ。Mercurialは、Python 3.0が出てから本気出すんだ。
今はその予習期間さ……。

915 ：デフォルトの名無しさん：2008/11/30(日) 22:41:29

>893
NFCは余計な気がするかな。
情報損失がある割に歴史的経緯で不十分な点も多いのであまり使えないと思う。

コミットログは英語でかけってのがベストな気はするけど、まぁこれも難しいんだろうな

916 ：デフォルトの名無しさん：2008/11/30(日) 22:43:31

hg clone static-http://example.com/my-project

>>913
remote な checkout ってのがよくわからんのだが、どういう動作を期待してるんだ？

917 ：デフォルトの名無しさん：2008/11/30(日) 22:44:53

>>916
svnのような動作

918 ：デフォルトの名無しさん：2008/12/01(月) 00:07:26

hg にそもそも checkout あったっけ…ってググってみたらあるみたいだな
clone しか使ってねーからよくわからんわ
つーか clone で良くね？って思ったけど
static-http に至っては http リクエストを減らせるかも知れないわけね…ｍｍｍ

919 ：デフォルトの名無しさん：2008/12/01(月) 00:21:42

なんか時期SVN候補だと思ってGitやMercurialさわってみたけど、
両方ともまだほとんど使えないのね。
Gitは環境がほぼlinuxオンリーだし、hgもウェブ越しでの公開はいろいろ面倒だったり・・・。

これって似たようなプロジェクトが乱立してるために、開発リソースが分散してしまったから？

920 ：デフォルトの名無しさん：2008/12/01(月) 00:26:40

>>918
hgはgit式のcheckoutはあったはずだけど、svnのようなのは無かったはず。bzrには両方あったはず。

>>919
乱立のせいでは無いと思うよ。
hgはツールは発達してるが構造が問題だし、gitは構造は問題無いがツールが問題。
というかbzr使えば良くね?

921 ：デフォルトの名無しさん：2008/12/01(月) 00:41:48

個人でいろいろ追いかけるのはおもろいけど、チームに導入するとなるとね・・・

922 ：デフォルトの名無しさん：2008/12/01(月) 01:00:07

このスレ見てると、svn除くとbzrが攻守ともに最強って気がしてくるが、
その割には実際使ってるの1～2人しか居ないような？

923 ：デフォルトの名無しさん：2008/12/01(月) 01:01:25

>>922
bzrスレ見るともっといそうだが、少ないことは確か

924 ：デフォルトの名無しさん：2008/12/01(月) 02:19:05

bzrは、日本語資料が少ないんだよ。
チュートリアルすら全部翻訳されたものが無い。

あと個人的にはブランチの方法が気に入らない。

925 ：デフォルトの名無しさん：2008/12/01(月) 02:19:09

>>921
安定しているsvnを選択する以外ないが手元のバージョンを細かくコミットしていくことができなくて不便だったりする。
svkは重いし

926 ：デフォルトの名無しさん：2008/12/01(月) 14:27:18

手元では Mercurial 、共有ストレージとして svn みたいな手はあるけどね。

927 ：デフォルトの名無しさん：2008/12/01(月) 19:00:29

共有ではsvn、手元では管理情報ディレクトリ名を.svnから_svnに変更したsvnって手もある。

928 ：デフォルトの名無しさん：2008/12/01(月) 21:06:40

hgやgitはやたらにディレクトリ作らない点が一番いいとこw
ローカルで使うだけならどれ使っても大差ないから、こういうとこで
選んでしまうな。

929 ：デフォルトの名無しさん：2008/12/01(月) 22:18:06

>>927
そんなことできるん？

930 ：デフォルトの名無しさん：2008/12/01(月) 22:22:53

>>925
つ git-svn、bzr-svn

931 ：デフォルトの名無しさん：2008/12/01(月) 22:53:58

bzrは開発速くて期待してるが、tortoiseが使い物にならないと無理。

932 ：デフォルトの名無しさん：2008/12/01(月) 23:22:30

>>920
>hgはツールは発達してるが構造が問題だし、gitは構造は問題無いがツールが問題。

これ、興味あるので、できればくわしく教えてください。
指定しない限り差分をとらないgitのほうが構造に問題があると思ってました。

933 ：デフォルトの名無しさん：2008/12/01(月) 23:27:32

Canonical Ltd.(Ubuntsを支援してるトコ)からバックアップを受けてるってのは強みかもね>Bzr

934 ：デフォルトの名無しさん：2008/12/02(火) 01:44:01

Canonical Ltd.(Ubuntsを支援してるトコ)からバックアップを受けてるから、
Windowsに利するような事はしないだろう＞ Tortoise

935 ：デフォルトの名無しさん：2008/12/02(火) 02:09:59

tortoiseBzrが一通り日本語通って外部diff出来るようになれば
あと、微妙に怪しいディレクトリに対するオーバーレイアイコンがちゃんとすれば

936 ：デフォルトの名無しさん：2008/12/02(火) 02:24:18

TortoiseBzrの現状はどうにゃの？

TortoiseHGの想像以上のクオリティの低さに、Subversionとその他大勢の差を
痛感してるところなんだが。

937 ：デフォルトの名無しさん：2008/12/02(火) 07:41:16

同じく。スレ上のbzr宣伝マンに釣られて使ってみたものの
tortoiseBzrのクオリティがまだβレベルだったので嘆いた。

938 ：デフォルトの名無しさん：2008/12/02(火) 07:43:06

それと、Tracプラグインももう少しなんとかならないと
会社では推進できないなぁ。残念。

939 ：デフォルトの名無しさん：2008/12/02(火) 09:04:16

TortoiseXXXのUIはみんなTortoiseSVNをそのまま使うってわけにはいかないんだろうか。

940 ：デフォルトの名無しさん：2008/12/02(火) 09:29:38

オプソ物ってコンセプトだけとりあえず形にして
ライブラリやツールといった環境整備で力尽きるパターンが多いよね。

941 ：デフォルトの名無しさん：2008/12/02(火) 09:45:33

多くの人は金が絡まなければ超面倒くさい手伝いはしたくないもの

942 ：デフォルトの名無しさん：2008/12/02(火) 10:29:43

TortoiseBzr はまだ experimental って書いてあるから、βどころかαだね。
今の Windows 7 みたいな立ち位置。

943 ：デフォルトの名無しさん：2008/12/02(火) 10:34:05

Mercurial にはガッカリ。
まあまだしばらく使うけど。

944 ：デフォルトの名無しさん：2008/12/02(火) 11:27:43

TortoiseBzrは遅いのが気になる

945 ：デフォルトの名無しさん：2008/12/02(火) 11:34:17

Git わかんねー
リモートリポジトリの hogehoge ブランチを取ってきたいんだけど
どうすればいいの？
マニュアルよんでもさっぱりさね

946 ：デフォルトの名無しさん：2008/12/02(火) 11:42:47

>>945
git clone とかだと思うが。
チュートリアル読んでも分からないか？
ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html

947 ：デフォルトの名無しさん：2008/12/02(火) 11:52:41

>>946
ありがとう。でもわかんない。
git clone はリポジトリ全体を持ってくるコマンドだよね。だから違うと思う。
チュートリアルには載ってないみたいだけど、もし載っているなら該当箇所を教えてください。

948 ：デフォルトの名無しさん：2008/12/02(火) 12:01:42

うろ覚えだが、たしかブランチのURLを指定して取ってくるコマンドがなかったっけ？
マニュアルは読んだことないからｼﾗﾈ

949 ：デフォルトの名無しさん：2008/12/02(火) 12:16:39

clone してから branch -r して確認後 checkout

950 ：デフォルトの名無しさん：2008/12/02(火) 12:30:37

>>949
そのcheckoutがわかりません。
git checkout hogehoge
git checkout -b hogehoge origin/hogehoge
git checkout -b hogehoge origin hogehoge
....
git --help checkout # 何書いているかさっぱり

ほんとにみんなgit使ってるんでしょうか。
あんなわかりにくいドキュメントでよく使いこなせますね。
いやみじゃなくて、ほんと尊敬します。

951 ：デフォルトの名無しさん：2008/12/02(火) 13:14:12

>>950
git checkout でチェックアウト出来てるでしょ？
マニュアルは細部まで書いてあるから、最初読んだらワケワカになるよ。
まずはチュートリアル読みなって。

952 ：デフォルトの名無しさん：2008/12/02(火) 18:30:41

>>951
git checkout でリポジトリはとってこれますけど、git branch しても master しかありません。
リモートの hogehoge ブランチをローカルにもってくる方法がわからなくて質問しています。

953 ：デフォルトの名無しさん：2008/12/02(火) 18:33:03

こういうキチガイに親切にレスをする人をぼくは尊敬します

954 ：デフォルトの名無しさん：2008/12/02(火) 18:46:06

まあちょっと図々しいかもな。

955 ：デフォルトの名無しさん：2008/12/02(火) 19:23:43

レスつけてるようで全然答えてないのになぜか偉そうなやつって確かにイラつくよな。
質問すらろくに読んでない場合も多いし。

956 ：偽蕪木ら某◇Googl8RmwA：2008/12/02(火) 19:30:39

>>945
% git clone /path/to/repos
% cd repos
% git branch -r
origin/hogehoge
origin/master
% git checkout -b hogehoge origin/hogehoge

957 ：デフォルトの名無しさん：2008/12/02(火) 19:35:23

質問スレじゃないし答える義務なんてねえんだけどな

958 ：デフォルトの名無しさん：2008/12/02(火) 19:38:24

質問スレだって義務なんてないよ

959 ：デフォルトの名無しさん：2008/12/02(火) 19:56:41

>>955
お前こそ良くレスを読め。
”確かに”って書いてるくせに言ってることが流れと真逆だぞ。

960 ：デフォルトの名無しさん：2008/12/02(火) 20:54:43

>>952
>>956の通りのやり方で出来るよ。
git branch -r でリモートのブランチが表示されるから、それをcheckout -b で
ローカルブランチにフォーク。
git checkout origin/hogehoge で直接チェックアウトも出来るが、これだと名無しブランチになる。
てかチュートリアル読めば分かるって。

961 ：デフォルトの名無しさん：2008/12/02(火) 21:10:52

設定ファイル見てオーバレイステータスと実行するコマンドを決める
マルチTortoiseを希望

962 ：デフォルトの名無しさん：2008/12/02(火) 21:31:17

アップデート後に再起動しなくていいTortoiseを希望

963 ：デフォルトの名無しさん：2008/12/02(火) 21:46:53

bzrはtortoise入れても再起動しなくて良かったような

964 ：デフォルトの名無しさん：2008/12/02(火) 21:51:33

クオリティが低すぎて、再起動を求めることすら忘れてるだけだろ。

965 ：デフォルトの名無しさん：2008/12/02(火) 21:56:15

Bazaar 1.9 rc1の時に意図的に再起動を無くしたという話らしい。

966 ：デフォルトの名無しさん：2008/12/02(火) 23:38:08

Bzr1.9 と Hg の速度比較した人いない？
まだHgの方がはやいの？

967 ：デフォルトの名無しさん：2008/12/02(火) 23:45:08

バージョン管理システムのベンチマークプログラムがあると良いと思った。
自転車置き場をどうするかで揉めて企画倒れしそうだが。

968 ：デフォルトの名無しさん：2008/12/03(水) 00:57:10

エクスプローラのアドインだから、エクスプローラだけ再起動してやればいいんだけどね。
ログオフでも可。

969 ：デフォルトの名無しさん：2008/12/03(水) 05:55:04

ちゅうか、そろそろシェルエクステンションの意味無くなってきてない？

970 ：デフォルトの名無しさん：2008/12/03(水) 06:38:20

上の話見たけど、全部 git clone で運用すればいいんでないの？
なんでわざわざ branch なんて概念があるの？

971 ：デフォルトの名無しさん：2008/12/03(水) 09:06:01

便利だから。

972 ：デフォルトの名無しさん：2008/12/03(水) 10:13:22

>>956
ありがとうございます。でも>950で書いたように、
>git checkout -b hogehoge origin/hogehoge
でもエラーになってうまくいきません。
もしかしたら何か別のことが原因でうまくいかないのかもしれません。

973 ：デフォルトの名無しさん：2008/12/03(水) 10:22:22

>>960
>てかチュートリアル読めば分かるって。

チュートリアルってこれですよね？
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial-2.html
探しましたけど、どちらにも載ってないと思います。
マニュアルの方にはそれらしきのがあって、>950のようにいろいろ試してみたけど、結局できなかったという状況です。

Subversionはコマンドもドキュメントもわかりやすかったのに。。。

974 ：デフォルトの名無しさん：2008/12/03(水) 10:43:05

だったらSVN使ってれば良いだろ
いちいち泣きつきに来るなよ

975 ：デフォルトの名無しさん：2008/12/03(水) 10:45:58

>>972
エラー内容見せてください

976 ：デフォルトの名無しさん：2008/12/03(水) 10:48:17

親切に答えようとしてる振りしてる自演乙

977 ：デフォルトの名無しさん：2008/12/03(水) 11:01:34

>>953
>>955
>>976
なんか妙に茶々入れる奴が一人いるな。

978 ：デフォルトの名無しさん：2008/12/03(水) 11:39:15

質問者も回答者もうざい。gitスレでやれ

979 ：デフォルトの名無しさん：2008/12/03(水) 12:16:02

うおー、checkout -b hogehoge origin/hogehoge がうまくいきました!

やったこと:
(1) git を 1.6 にアップデートして
(2) リポジトリを checkout し直して
(3) checkout -b hogehoge origin/hogehoge

うまくいかなかった原因は、git が古かったせいかもしれないし、
いろいろ試したせいでリポジトリがおかしくなってたのかもしれません。
とにかく最新版の git でチェックアウトし直したら、>956の通りにいけました。
偽蕪木ら某◇Googl8RmwA さま、辛抱強くアドバイスくださりありがとうございました。

でもgitわかりにくいよ。。。

980 ：デフォルトの名無しさん：2008/12/03(水) 18:03:42

だからgitなんかやめて、bzr使えばいいんだよ。
bzr使いやすくて最高だよ。俺は使った事無いけど。

981 ：デフォルトの名無しさん：2008/12/03(水) 18:16:40

>>980
志村ー矛盾矛盾！

982 ：デフォルトの名無しさん：2008/12/03(水) 19:32:57

gitのwindows版インストールしてみたんだけど、GUIは意味不明のエラーで起動しないわ、
git cloneも同じく意味不明のエラーで止まるわでダメダメだったぞ

983 ：デフォルトの名無しさん：2008/12/03(水) 19:34:10

>>982
　>>980

984 ：デフォルトの名無しさん：2008/12/03(水) 20:01:31

gitやめて、bzr入れてみた。
bzr評判が良いだけあって最高だな。まだ起動してないけど。

985 ：982：2008/12/03(水) 20:11:22

ちなみに俺がインストールしようとしたのは、msysgitってやつ。
msysでもcygwinでもない、Windowsネイティブバイナリ無いの？

986 ：デフォルトの名無しさん：2008/12/03(水) 21:04:52

誰も使ってないけど至高のバージョン管理ツールbzr for Human Beings

987 ：デフォルトの名無しさん：2008/12/03(水) 23:32:33

hgが1.1になってたんで簡単なsvn/hg/bzr比較ベンチマークしてみた。
gitは使うきないので対象外。
環境：
　AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
　Memory 2GB
データ：
　svn export svn://gcc.gnu.org/svn/gcc/tags/gcc_3_4_2_release gcc_3_4_2
　svn export svn://gcc.gnu.org/svn/gcc/tags/gcc_3_4_3_release gcc_3_4_3
結果： SVN(ver 1.5.1), HG(ver 1.1), BZR(ver 1.9)

　　　　　　　　　SVN　　HG　　　BZR(fmt1.6)　BZR(fmt1.9)
3_4_2のコミット　1m17s　33s　　　40s　　　　　39s
3_4_2のpush　　　ー　　　34s　　　55s　　　　　53s
3_4_3のマージ　　6m30s　2s　　　17s　　　　　　7s
マージ後push　　　ー　　　2s　　　15s　　　　　　14s
レポジトリサイズ　119MB　116MB　295MB　　　　263MB

この結果だとまだまだhgの方がよさそうだ。
bzrのレポジトリサイズはちょっと耐えがたいか。
速度は秒単位であればbzrでも我慢できるが。

988 ：デフォルトの名無しさん：2008/12/03(水) 23:34:56

OSは?

989 ：デフォルトの名無しさん：2008/12/03(水) 23:50:59

ubuntu 8.10です。

990 ：デフォルトの名無しさん：2008/12/03(水) 23:57:09

>>970
分散型だったらclone+commitでブランチができちゃうのは宿命。
それに名前をつけたいことやあるだけ。

991 ：デフォルトの名無しさん：2008/12/04(木) 01:38:08

subversionのレポジトリの中ではファイル圧縮されてるらしいからなあ

992 ：デフォルトの名無しさん：2008/12/04(木) 01:52:07

>987
リビジョンが増えるにつれて、全コピーするhgのレポジトリサイズはどんどん増えていくでしょ。
svnはHEAD以外はリモートに置くから、影響が小さい。
bzrは--stackedオプションがあるから、まだ軽減される。
開発チーム内にデザイナが居て、画像ファイルとか差し替えると、これは顕著になる。

ああ、またbzr万能論を補強してしまった。

993 ：デフォルトの名無しさん：2008/12/04(木) 07:14:18

>>992
それで、>>987のケースでbzrのレポジトリサイズが
有利になるクロスポイントはどのくらいレビジョンが
上がったときになるのかな？
机上の空論を唱えられるより実用的な数字が知りたいわけ。
そして--stackedをつけるとどのくらいの量が減るのかな。
そこんところkwsk

994 ：987：2008/12/04(木) 07:26:14

svnは当然ながら、hgもbzrも空の中央レポジトリを作り、
clone/branch作ってファイルをコミットしてから中央レポジトリ
へpushし、中央レポジトリのサイズを計ってる。
従って、svn/hg/bzrでのレポジトリ計測の条件は同じのはず。
>>992の
>svnはHEAD以外はリモートに置くから、影響が小さい。
は関係なく、svn/hg/bzrどれがどれより有利な条件という
ことはない。

995 ：デフォルトの名無しさん：2008/12/04(木) 09:07:43

>>987
http://bazaar-vcs.org/BzrVsHg#Storage-Efficiency

fmt 1.6以降は容量効率悪いのかな？

996 ：デフォルトの名無しさん：2008/12/04(木) 12:37:15

>>987
bzrはスマートサーバー使ってる?

997 ：デフォルトの名無しさん：2008/12/04(木) 13:25:01

>>992 リビジョンが増えるにつれて、全コピーするhgのレポジトリサイズはどんどん増えていくでしょ。
差分をとるはずだよ (hgbook 4.2.1)

998 ：デフォルトの名無しさん：2008/12/04(木) 13:55:28

次スレよろしく

999 ：デフォルトの名無しさん：2008/12/04(木) 13:58:01

立てられんかった。

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

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

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

1000 ：デフォルトの名無しさん：2008/12/04(木) 14:03:24

立てますた
バージョン管理システムについて語るスレ3
http://pc11.2ch.net/test/read.cgi/tech/1228366972/

1001 ：１００１：Over 1000 Thread

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