Subversionリポジトリのブランチの1つを新しいトランクにする最良の方法は何ですか？
システム全体が大幅に書き直されました。移動、書き換え、置換、削除、名前変更などが行われました。書き換えられたコードはテスト済みで、古いトランクを置き換える準備ができています。
基本的に、古いメインライン（トランク5）にタグが付けられ、ここで終了します。書き直されたブランチ（ブランチ6）は、新しいメインライン（トランク7）になります。
トランク（1）->トランク（2）->トランク（5）->×+->新しいトランク（7）
\ \ |
フォークマージ???
\ \ |
+-> Branch（3）-> Branch（4）-> Branch（6）-+
古い「トランク」からの継続的な変更はすべて「書き換えられたブランチ」にすでに組み込まれています
これどうやってするの？
回答:
svn moveを使用して、古いトランクの内容を別の場所に移動し、ブランチの名前を後からトランクに変更します。
svnでのコピーと移動は、ファイル操作のように機能することに注意してください。それらを使用して、リポジトリ内の移動やコピーを行うことができ、これらの変更もバージョン管理されます。「移動」は「コピー+削除」と考えてください。
[編集]を使用するとマージの競合が発生することがNilbusから通知されましたsvn move。
私は今でもこれが正しいアプローチだと思います。競合が発生しますが、慎重にマージすると、データが失われない可能性があります。それが気になる場合は、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
私のトランクの作業コピーに。
これは、歴史的な方法で変更を適用しようとはしません（トランクの変更を維持します）。トランクとブランチの間に「差分を適用」するだけです。これにより、変更されていないファイルでユーザーの競合が発生することはありません。ただし、ブランチから履歴情報が失われますが、それでもマージを実行すると発生します。
これらの変更は、リポジトリブラウザツールを使用して行うことをお勧めします。
作業コピーを介して大規模な削除と移動の操作を試みることは、作業コピーを強制終了するための優れた方法です。作業コピーを使用する必要がある場合は、削除または移動操作のたびに増分コミットを実行し、コミットごとに作業コピーを更新します。
@Aaron Digullaおよび@kementeusソリューションは実行可能です。Subversion 1.4リポジトリの場合、コピー/移動操作により、別のリポジトリ構造への将来の移行やリポジトリの分割が困難になる可能性があります。
1.5の改善には、移動/コピー履歴のより良い解決が含まれていると思います。そのため、1.5リポジトリでは問題にならないでしょう。
1.4リポジトリの場合は、を使用svnadmin dumpしsvndumpfilterて既存のトランクを別の場所に移動してから、同じメカニズムでブランチをトランクに移動することをお勧めします。2つのダンプファイルをテストリポジトリにロードし、確認して、本番環境に移動します。
もちろん、開始する前に既存のリポジトリをバックアップしてください。
これにより、移動/コピーを明示的に記録せずに履歴が保持され、将来の再編成、履歴の保持が容易になります。
編集：要求どおり、1.4 Red-BeanブックのFiltering Repository Historyからの1.4動作のドキュメント
また、コピーされたパスは問題を引き起こす可能性があります。Subversionは、既存のパスをコピーすることによって新しいパスが作成されるリポジトリでのコピー操作をサポートしています。リポジトリの存続期間のある時点で、ファイルまたはディレクトリ
svndumpfilterを、除外されている場所から、それが含まれている場所にコピーした可能性があります。ダンプデータを十分なものにするために、svndumpfilterは、新しいパスの追加（コピーによって作成されたファイルの内容を含む）を表示する必要があり、フィルターされたダンプデータストリームに存在しないソースからのコピーとしてその追加を表す必要はありません。ただし、Subversionリポジトリのダンプ形式は各リビジョンで変更されたもののみを表示するため、コピー元のコンテンツをすぐに利用できない場合があります。リポジトリにこの種のコピーがあると思われる場合は、含まれている/含まれていないパスのセットを再考する必要があるかもしれません。
これは、を使用した移行/再編成に適用されますsvndumpfilter。少し余分な作業を行うことで、後で多くの余分な作業を節約できる場合がsvndumpfilterあります。将来の移行/再編成で使用できるようにしておくことで、比較的低コストでリスクを軽減できます。
上記の答えは機能しますが、ベストプラクティスではありません。最新のSVNサーバーとクライアントトラックがマージされます。そのため、svnはブランチにマージしたリビジョンとその場所を知っています。これは、ブランチを最新の状態に保ち、その後トランクにマージするときに非常に役立ちます。
ただし、使用しているSubversionのバージョンに関係なく、ブランチの変更をトランクに戻すためのベストプラクティスの方法があります。これについては、Subversionマニュアルの「Subversionによるバージョン管理」の第4章「ブランチとマージ、ブランチの同期を保つ」で概説されています。
これはSVNでの非常に奇妙な/異常な構成ですが、「良い習慣」には程遠いと思いますが、とにかく、次のようなことができると思います。
幸運を