私たちはSubversion Geeksであり、Mercurialの利点を知りたい[非公開]

私はSubversionオタクだということを読んだので、なぜMercurialやGitまたはその他のDVCSを検討すべきか、検討すべきではないのか。

関連するフォローアップの質問があります。私はその質問を読み、推奨されるリンクとビデオを読んで、その利点を見ましたが、人々が話している全体的なマインドシフトは見ていません。

私たちのチームは、60のプロジェクトで構成される1つの大きなコードベースで作業する8〜10人の開発者です。Subversionを使用し、メイントランクを持っています。開発者が新しいFogbugzケースを開始すると、svnブランチが作成され、ブランチ上で作業が行われ、完了したらトランクにマージされます。場合によっては、ブランチに長時間滞在し、トランクにブランチをマージして変更を反映することがあります。

Linusがブランチを作成し、二度とブランチを作成しないことについて話すのを見たとき、それはまったく私たちではありません。おそらく週に50〜100のブランチを問題なく作成します。最大の課題はマージですが、私たちもそれをうまく得ています。ブランチのルート全体ではなく、fogbugz case＆checkinでマージする傾向があります。

リモートで作業することも、ブランチからブランチを作成することもありません。コードベースのそのセクションで作業しているのがあなただけなら、トランクへのマージはスムーズに進みます。他の誰かがコードの同じセクションを変更した場合、マージが面倒になり、手術が必要になる場合があります。競合は競合です。コードを理解できるほど賢くなければ、ほとんどの場合、どのシステムでもそれを正しく実現できるとは思いません。

ブランチを作成した後、以下の60k +ファイルのチェックアウトには時間がかかりますが、これは使用するソース管理システムの問題です。

DVCSには、私たちにとって大きな助けになるとは思えない利点がありますか？

「DVCSを集中的に使用することのみを計画している場合、どのようなメリットがありますか」という質問を言い換えます。あなたがそのように尋ねるとき、それはしません。VCSでは、タスクごとに1つのブランチが非常に一般的です。考えてみると、開発者のマシン上で1日にトランクから独立して変更されるソースコードのローカル作業コピーを作成することは、誰も呼び出していない場合でもブランチです。それとあなたのワークフローの唯一の違いは、中央サーバーでもそれらのブランチに永続的な名前を付けることです。それは、Linusや他の人が話している種類の分岐ではありません。

DVCSを理解するには、考え方を根本的に変える必要があります。あなたは、あなたが望む誰とでも共有される、あなたが望むだけ多くのブランチで何をするかを自分自身に問う必要があります。これには、自分だけが見るブランチが含まれます。

可能性は無限大。ほんの一例として、インターフェイスの反対側で作業している2人はどうでしょうか。彼らは定期的にお互いにコードを共有する必要がありますが、まだ誰とでも共有できるほど安定していません。ブランチを作成して共有し、準備ができたらブランチを中央リポジトリにマージします。

中間のローカルコミットを行う機能は、それだけで価値があります。それはあなたが自分で経験しなければならないことです。

リポジトリをローカルにすることで得られる速度も、それだけで価値があります。はい、60kファイルレポジトリの場合、VCSでは最初のクローンはやむを得ず遅くなりますが、それができたら、DVCSを使用すると新しいブランチのチェックアウトが桁違いに速くなります。

特定のケースでは、DVCSに切り替えるメリットはありません。既存のシステムに満足しているので、必要なすべてが実行されるので、切り替えてください。SVNはまだアクティブなオープンソースプロジェクトであり、すべての主要なIDEおよび開発ツールとhgまたはgitよりも優れた、より成熟した統合を持っています。チームの規模とプロジェクトの数を考えると、既存のツールが正常に機能しているときに、新しいツールに変換するのに時間をかけたいですか？

DVCSなしでは機能できない開発者がいる場合は、hgまたはgitのsvnゲートウェイを指定します。svnリポジトリへのチェックインは、他のチームが使用するすべての手順とプロセスに準拠する必要があることを彼らに明確に伝えてください。このアプローチのもう1つの利点は、クローゼットから抜け出すことができるとは言わずにゲートウェイを既に使用している真のDVCS熱狂者がいることです:-)。

DVCSを使い始めてから多くの人が採用するワークフローに非常によく似たワークフローを既に使用しているように思えます。

あなたの観点からすると、DVCSにはSVNに比べて次の重要な利点があります。

• リポジトリのクローンを作成したら、多くの操作をローカルで実行できます。
  • リポジトリログを見るのは、svnサーバーに触れる必要がないので、信じられないほど高速です。
  • 同様に、ブランチの切り替えにはサーバーへのアクセスもローカルクローンも必要ありません。
• ブランチは履歴の単なる分岐パスであるため、リポジトリは誰もが作成したすべてのブランチで散らかっていません（SVNにはリリースブランチのみがありますが、branchesディレクトリにはまだ関係のない多くのサブディレクトリがあります）。
  • gitでは、ブランチが再びマージされ、refが削除されると、ブランチがそこにあることさえ知らないかもしれません。
  • Mercurialのでは、の選択肢を持っているのいずれか（その場合、それは永久に各チェンジセットにエンコードされます）ブランチに名前を付けるか、単に静かになります。名前（位相幾何学）支店、作成マージそれがあるとき、歴史の中にmergeにDバックをdefault（trunk）
• SVNでは、ブランチのブランチはあまりにもわかりにくいため、有用ではありません。でgit、hg彼らはコースのちょうどパーです。
• DVCSは、ソフトウェア開発がDAGであると理解しています。つまり、マージすると、複数の親を持つ変更セットになります。SVN（少なくとも私が使用したバージョン）はこれを本当に理解していません。

その最後の点で、あなたは言う

競合は競合です。コードを理解するのに十分なほどスマートでない限り、ほとんどの場合、どのシステムでもそれを正しく実現できるとは思いません。

hg排他的に使用することからsvn単独で使用するように切り替えるgitsvnことで、マージがはるかに単純でトラブルフリーでhgありgitsvn、それよりもトラブルが少ないことが私の経験svnでした。svn（少なくとも使用しているバージョンと）マージすると、手動で解決する必要があるかなり多くの競合が発生します。

SVNでマージが難しい理由の1つは、異なる行ごとに2つのオプションしか提供しないことです。

• マージするブランチのテキスト
• マージするブランチのテキスト

DVCSからのマージでは、通常3番目のオプションが提供されます。

• マージする両方のブランチの共通の祖先からのテキスト

これがどれだけ有益な過小評価しないでください、それはをご提供して多くの可能性シンプルな2ウェイデフよりも変化のためのより良い状況。

全体として、試してみることをお勧めします。gitsvnやなどのツールを使用hgsubversionすると、現在のSVNリポジトリで試してみることができます。

^{そもそもクローンを作成するのは王室のPItAですが、一度それを行うと、既存のCVCSでDVCSのパワーを最大限に活用できます。}

このような移行後に気付いた重要な変更が1つあります。ブランチを頻繁に切り替えることと、Subversionで余裕がなかったより頻繁にコミットすることです。たとえば、いくつかの小さな機能ブランチが順番に整理されており、それぞれにビットを追加して、変化するトランクにすべてを順番に簡単にリベースすることができます。機能ブランチをマージする順序を再調整するのは簡単です。

しかし、実際には、私は実際にはSubversionから離れていません。ローカルsvnクライアントとしてgitを使用しています。