SVNができないこと

SVN 1.5がリリースされたとき、同僚と私は変更の転送（マージ）の履歴を記録するための待望のサポートについて非常に満足していたことを覚えています。それまでは編集へのコメントに含まれていましたが、もちろんこれは本当に私たちを悩ませました。 祝うために、この新しい機会をどのように使用するか、さまざまなアイデアが思い浮かび始め、いったん助けを借りてソースコードレベルでモジュール性を実装することに決めました。



アイデアは、通常行われているように、実行時に個別のライブラリを接続するのではなく、個別のブランチの異なるプロジェクトで再利用される機能を選択し、必要に応じて新しいプロジェクトに転送することでした。





プラットフォームのメインブランチを5つのモジュールブランチから分岐させ、それぞれに1つの個別のモジュールの機能を追加し、トランクからモジュールに変更を転送することで関連性を維持しました。



すべてが順調でした。 いくつかの特定のモジュールを含むディストリビューションを構築する必要がある場合、トランクから新しいプロジェクトを分岐し、必要なモジュールの分岐から順次変更を転送しました。



しかし、特定のプロジェクトを開発する過程で、コード、さらにはメイントランクコードと擬似モジュールのコードの両方の改善と修正の必要性に直面しました。 当然のことながら、これらの有用な変更は、将来のプロジェクトに取り入れるために、トランクとモジュールブランチに戻す必要がありました。



そして、ここで私たちは予期せぬ効果に直面しています。 SVNは、ブランチに転送された変更の履歴をルートフォルダのプレーンテキストプロパティに保存します。 プロパティテキストは、変更が転送されたブランチのリストであり、どのリビジョンが転送されたかを示します。



したがって、私たちの場合のSVNでのミキシングメカニズムの実装の主な機能は、変更を転送すると、1つのブランチから別の小さな編集まで、すべてのマージ履歴もこの編集とともに完全に転送されることです。



そして、これが私たちに起こったことです。 モジュールを含むプロジェクトからトランクに変更を転送すると、これらのモジュールの統合に関する記録もトランクに落ちました。 そして、トランクからの次のすべてのプロジェクトは、以前にこれらの変更をすでに受け取っていたことを考慮して、モジュールのコードを受け入れることをすでに拒否しました。



また、SVNには、この場合の重要な制限が1つあり、その意味は次のように説明できることがわかりました。 変更の伝達経路に閉回路が形成されることは不可能です 。



異なるルールを考え出すことでこれらのパスを最適化しようとし、変更をクラスに分割し、それぞれに個別のルールを設定しましたが、結局、これはすべて複雑すぎて不便であることに気づき、ソースレベルで非常に気に入っていたモジュール性の考え方を捨てて、置き換えました通常の実行時のモジュール性。



最近、分散バージョン管理システム、特にMercurialとGitについて友人から絶賛のレビューがますます増えています。 そして、私は質問がありました、これらのシステムでそのような複雑な変更転送スキームを編成することは可能ですか？



これらのシステムまたは他のシステムを使用している人々に、説明した問題を引き起こすことなく、それらの変更を閉回路に沿って転送できるかどうかを尋ねますか？ たとえば、次の図では、マージ編集8を実行できますか？ また、システムは9の再移行の試みをブロックしますか？



たとえば、SVNは両方をブロックします。











UP： tzlomによると、Gitを使用すると両方の編集が可能であり、当然、9日目に衝突が発生します。 一般に、SVNではロックを無視することもできます。その場合、効果は同じになります。



UP： PQRは、Mercurialでの編集はTransplant拡張機能を使用してアトミックに転送でき、Gitではcherry-pickコマンドを使用して編集できることを提案しましたが、明らかに、両方の編集が両方のケースで許可されます（8および9）。