Subversionリポジトリのブランチの1つを新しいトランクにする最良の方法は何ですか?
システム全体の大幅な書き換えが行われました。物事の移動、書き換え、置換、削除、名前変更などが行われました。書き換えられたコードはテスト済みで、古いトランクを置き換える準備ができています。
基本的に、古いメインライン(トランク5)にタグが付けられ、ここで終了します。書き直されたブランチ(ブランチ6)は新しいメインライン(トランク7)になります。
Trunk(1)-> Trunk(2)-> Trunk(5)->×+-> new Trunk(7) \\ | fork merge ??? \\ | +-> Branch(3)-> Branch(4)-> Branch(6)-+
古い「トランク」からのすべての進行中の変更は、「書き直されたブランチ」にすでに組み込まれています
どうすればいいですか?
svn move を使用して、古いトランクの内容を別の場所に移動し、その後ブランチの名前をtrunkに変更します。
Svnでのコピーと移動は、ファイル操作のように機能することに注意してください。これらを使用して、リポジトリ内のアイテムを移動/コピーできます。これらの変更もバージョン管理されます。 「移動」を「コピー+削除」と考えてください。
[編集] svn move
を使用するとマージの競合が発生することをNilbusから通知されました。
私はまだこれが正しいアプローチだと思います。競合が発生しますが、慎重にマージすると、データが失われない可能性があります。それが気になる場合は、 Mercurial または Git のようなより良いVCSを使用してください。
この目標を達成するためにsvn moveコマンドを使用することに同意します。
ここにいる他の人たちは珍しいと思いますが、私はそれをこのようにしたいです。機能ブランチがあり、大幅に変更されたトランクとマージする準備ができたら、通常<FeatureBranchName>-Merged
という名前の新しいブランチにマージします。次に、競合を解決し、マージされたコードをテストします。それが完了したら、トランクをタグフォルダーに移動して、何も失わないようにします。最後に、<FeatureBranchName>-Merged
をトランクに移動します。
さらに、移動を行うときに作業コピーを避けることを好みます。コマンドのサンプルを次に示します。
svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName
svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk
注:1.5を使用します
私は最近この問題を見ていましたが、私がとても満足していた解決策は
svn merge --ignore-ancestry trunk-url branch-url
トランクの作業コピーに。
これは、歴史的な方法で変更を適用しようとはしません(トランクの変更を維持します)。単にトランクとブランチの間に「差分を適用」します。これにより、変更されていないファイルにユーザーの競合が発生することはありません。ただし、ブランチから履歴情報は失われますが、とにかくマージを実行すると発生します。
これらの変更は、リポジトリブラウザツールを使用して行うことをお勧めします。
作業コピーを介して大規模な削除と移動の操作を試みると、作業コピーを強制終了できます。強制的に作業コピーを使用する場合は、削除または移動操作のたびに増分コミットを実行し、コミットごとに作業コピーを更新します。
ブランチを新しいトランクにする(つまり)ブランチの作成以降に行われたトランク内のすべての変更を取り除くには、1。トランクのブランチを作成します(バックアップのため)2. "変更を元に戻す」(トランクが作成された後、すべてのリビジョンを選択します3.ブランチをトランクにマージします。
歴史はこのように残っているはずです。
よろしく、ロジャー
@Aaron Digullaおよび@kementeusのソリューションは実行可能です。 Subversion 1.4リポジトリの場合、コピー/移動操作により、別のリポジトリ構造への将来の移行またはリポジトリの分割が困難になる場合があります。
1.5の改善には、移動/コピー履歴のより良い解決が含まれていると思われるため、おそらく1.5リポジトリでは問題になりません。
1.4リポジトリの場合、svnadmin dump
とsvndumpfilter
を使用して既存のトランクを他の場所に移動し、同じメカニズムでブランチをトランクに移動することをお勧めします。 2つのダンプファイルをテストリポジトリにロードし、検証してから本番環境に移動します。
もちろん、開始する前に既存のリポジトリをバックアップしてください。
これにより、移動/コピーを明示的に記録せずに履歴が保持され、将来の再編成が容易になり、履歴が保持されます。
編集:要求に応じて、1.4 Red-Beanブックの1.4動作のドキュメント Filtering Repository History
また、コピーされたパスは問題を引き起こす可能性があります。 Subversionは、既存のパスをコピーして新しいパスを作成するリポジトリでのコピー操作をサポートしています。リポジトリのライフタイムのある時点で、
svndumpfilter
が除外している場所から、それを含む場所にファイルまたはディレクトリをコピーした可能性があります。ダンプデータを自給自足にするために、svndumpfilter
は、コピーによって作成されたファイルのコンテンツを含む新しいパスの追加を表示する必要があり、その追加をソースからのコピーとして表さないフィルターされたダンプデータストリームには存在しません。ただし、Subversionリポジトリダンプ形式は各リビジョンで変更された内容のみを表示するため、コピーソースの内容はすぐに利用できない場合があります。リポジトリにこの種のコピーがあると思われる場合は、おそらく厄介なコピー操作のソースとして機能するパスも含めて、含める/除外するパスのセットを再検討する必要があります。
これは、svndumpfilter
を使用した移行/再編成に適用されます。少し余分な作業を行うと、後で多くの余分な作業を節約できる場合があり、将来の移行/再編成に使用できるsvndumpfilter
を簡単に使用できるようにすることで、比較的低コストでリスクを軽減できます。
上記の回答は有効ですが、ベストプラクティスではありません。最新のsvnサーバーとクライアントがマージを追跡します。したがって、svnは、ブランチにマージしたリビジョンとその場所を認識しています。これは、ブランチを最新の状態に保ち、それをトランクにマージして戻す際に非常に役立ちます。
ただし、使用しているSubversionのバージョンに関係なく、ブランチの変更をトランクに戻すベストプラクティスの方法があります。 Subversionマニュアルに概要があります: Subversionによるバージョン管理、第4章分岐とマージ、同期状態での分岐の保持 。