私たちはSubversion Geeksであり、Mercurialのメリットを知りたい
私はSubversionオタクですが、なぜMercurialやGit、その他のDVCSを検討する必要があるのか です。
関連するフォローアップ質問があります。私はその質問を読み、推奨されるリンクとビデオを読み、利点を確認しましたが、全体的なマインドシフトについて人々が話しているのを見ていません。
私たちのチームは、60のプロジェクトで構成される1つの大きなコードベースで作業する8〜10人の開発者で構成されています。 Subversionを使用しており、メイントランクがあります。開発者は、新しいFogbugzケースを開始すると、svnブランチを作成し、ブランチで作業を行い、完了したらトランクにマージします。ときどき、ブランチに長時間留まり、トランクをブランチにマージして変更を反映することがあります。
Linusが人々がブランチを作って二度とそれをやらないことについて話すのを見たとき、それは私たちではありません。おそらく、問題なく週に50〜100のブランチを作成します。最大の課題はマージですが、それもかなりうまくいきました。私はブランチのルート全体ではなく、fogbugzケースとチェックインでマージする傾向があります。
リモートで作業したり、ブランチからブランチを作成したりすることはありません。コードベースのそのセクションで作業しているのがあなただけの場合、トランクへのマージはスムーズに進みます。他の誰かが同じコードセクションを変更した場合、マージは煩雑になり、いくつかの手術が必要になる場合があります。競合は競合です。コードを理解できるほど賢くなければ、ほとんどの場合、どのようにしてシステムがそれを正しく行うことができるかはわかりません。
ブランチを作成した後、次の60k以上のファイルのチェックアウトには時間がかかりますが、これは、使用するソース管理システムの問題です。
DVCSには、私たちにとって大きな助けになるとは考えていないいくつかの利点がありますか？
「一元化された方法でDVCSのみを使用することを計画している場合、それはどのような利点がありますか？」そのように尋ねると、そうではありません。 VCSでは、タスクごとに1つのブランチが非常に一般的です。考えてみれば、開発者のマシンにソースコードのローカル作業コピーを1日間トランクとは独立して変更することは、誰もそれと呼ばなくても分岐です。それとあなたのワークフローとの唯一の違いは、それらのブランチに中央サーバー上の恒久的な名前も与えることです。それは、Linusや他の人たちが話しているような分岐ではありません。
DVCSを理解するには、考え方を根本的に変える必要があります。あなたは、あなたが望む誰とでも共有される、あなたが望むだけの数のブランチで何をするか、そしてそれらだけで何をするかを自分自身に問う必要があります。これには、自分だけが見るブランチが含まれます。
可能性は無限大。ほんの一例として、2人がインターフェイスの反対側で作業するのはどうでしょうか。彼らは定期的にコードを互いに共有する必要がありますが、まだ誰とでも共有できるほど安定していません。ブランチを作成して共有し、準備ができたら中央リポジトリにマージできます。
中間のローカルコミットを実行する機能は、それだけでそれだけの価値があります。それはあなた自身のために経験しなければならないものです。
リポジトリをローカルにすることで得られるスピードは、それだけでも価値があります。はい、最初のクローンは60kファイルリポジトリのどのVCSでもやむを得ず遅くなりますが、それができたら、DVCSを使用すると新しいブランチのチェックアウトが桁違いに速くなります。
多くの人がDVCSの使用を開始した後に採用するワークフローと非常によく似たワークフローを既に使用しているようです。
あなたの観点から見ると、DVCSにはSVNよりも次のような大きな利点があります。
- リポジトリのクローンを作成すると、多くの操作をローカルで実行できます。
- リポジトリのログを確認するのにsvnサーバーに触れる必要はないので、信じられないほど高速にできます。
- 同様に、ブランチの切り替えにはサーバーへのアクセスも、ローカルクローンも必要ありません。
- ブランチは単に履歴の分岐パスであるため、リポジトリは乱雑ではありません誰もが作成したすべてのブランチ（実際にはreleaseSVNで分岐しますが、
branchesディレクトリには、関係のない多くのサブディレクトリがまだあります）。- Gitでは、ブランチがマージされてrefが削除されると、ブランチがそこにあることさえ知らないかもしれません。
- Mercurialでは、ブランチに名前を付けるか（この場合、永続的に各チェンジセットにエンコードされます）、または静かにmergeに名前のない（トポロジ）ブランチを作成するかを選択できます。
mergedがdefaultに戻ったときの履歴（trunk）
- SVNでは、ブランチのブランチはあいまいすぎて役に立たない。
gitとhgでは、コースの標準に過ぎません。 - DVCSは、ソフトウェア開発が [〜＃〜] dag [〜＃〜] であることを理解しています。つまり、マージすると、複数の親を持つチェンジセットが作成されます。 SVN（少なくとも私が使用したバージョン）はこれを本当に理解していません。
その最後の点で、あなたは言う
競合は競合であり、コードを理解するのに十分なほど賢くなければ、ほとんどの場合、どのようにしてシステムがそれを正しく行うことができるかはわかりません。
hgのみを使用することからsvnを単独で使用し、次にgitsvnを使用することに切り替えると、マージはmuchhgおよびgitsvnを使用すると、svnを使用する場合よりも簡単で問題が発生しません。 svn（少なくとも、使用するバージョン）とマージすると、手動で解決する必要のある競合が大幅に増加します。
SVNでマージがより難しい理由の1つは、異なる行ごとに2つのオプションしか提供しないことです。
- マージするブランチからのテキスト
- マージするブランチからのテキスト
dVCSからのマージでは、通常、3番目のオプションが提供されます。
- マージする両方のブランチの共通の祖先からのテキスト
これがどれほど有益であるかを過小評価しないでください。これにより、単純な2方向のdiffよりも変更のコンテキストがmuchより適切になります。
全体として、私はあなたにそれを試してみることをお勧めします。 gitsvnやhgsubversionなどのツールを使用すると、現在のSVNリポジトリでそれらを試すこともできます。
最初にクローンを作成することはロイヤルPItAであることに注意してください。ただし、これを実行すると、既存のCVCSでDVCSの機能を最大限に活用できます。
特定のケースでは、DVCSに切り替えてもメリットはありません。あなたは既存のシステムに満足しています、それはあなたが必要とするすべてをします、それでなぜ切り替えますか？ SVNはまだアクティブなオープンソースプロジェクトであり、hgやgitよりもすべての主要なIDEおよび開発ツールとの統合が優れています。チームの規模とプロジェクトの数を考慮して、既存のツールが正常に機能しているときに、時間をかけて新しいツールに変換したいですか？
DVCSなしでは機能できない開発者がいる場合は、それらにhgまたはgitのsvnゲートウェイを指定します。 svnリポジトリへのチェックインは、チームの他のメンバーが使用する手順とプロセスに準拠する必要があることを明確に伝えます。このアプローチのもう1つの利点は、通知せずにゲートウェイをすでに使用している真のDVCS熱狂者が、クローゼットから出られるようになることです:-)。
そのような移行の後に気付いた重要な変更が1つあります。ブランチを頻繁に切り替え、Subversionでこれまでにないほど頻繁にコミットします。たとえば、いくつかの小さな機能ブランチがあり、それらは順番に編成されています。数か月かけてそれぞれにビットを追加し、常に変化するトランクに簡単に順番にリベースできます。機能ブランチがマージされる順序を並べ替えることは簡単です。
しかし、実際には、私は実際にはSubversionから離れていません。私はローカルsvnクライアントとしてgitを使用しています。