SVN 1.5へのアップグレード

Question

私が理解している小さなことから、svn 1.5はマージ操作のサポートがはるかに優れています。だから私はsvn 1.4からのアップグレードを検討しています。リポジトリはローカルファイル（ほぼ）にあり、コマンドラインからsvnを使用します。

どのようなハードルが予想されますか。svn1.5は、マージデータなしで既存のリポジトリをどのように処理しますか？

編集： 特に、 svnadmin upgrade を実行した後、svnは1.4時代に最後にマージされたブランチからのマージをどのように処理しますか？

そして、 svn-populate-node-origins-index はこれと何か関係がありますか？

リファレンス： http://subversion.tigris.org/svn_1.5_releasenotes.html

Answer 1

アップグレードはスムーズに行われる必要がありますが、merge-infoが読み込まれるまで魔法のマージの利点は得られません-これは使用を開始するまで発生しません。

私が見つけたマージ情報の唯一の明白な利点は、2つのブランチ間の潜在的なマージのリストを表示し、どのリビジョンが既にマージされているかを知ることができることです。生成される競合の数などには直接影響しませんが、どこに行ったのかを追跡する際に正気を保つことができます。アップグレードの前に実行されたマージは問題を引き起こしません。すでに実行されていても、潜在的なマージとして再び表示されます。

とはいえ、マージ情報はsvn：mergeinfoと呼ばれるsvnpropertyの形式で、次の形式です。

/Project/name/trunk:1355-3985,4019,4026-4437,4478,4481

これは、プロジェクトリリースブランチの1つの実際のmerge-infoであり、trunkのどのリビジョンがリリースされようとしているのかを正確に示しています。 つまり、必要な場所で解決できる場所であれば、mergeinfoを手動で入力し、すべての利点を得ることができます。これが上記の初期のリビジョンで行ったことです。

特にリポジトリが大きく、窓の上にあります。 1.4 fsfsリポジトリ形式では、すべてのリビジョンが同じフォルダ内の個別のファイルに配置され、Windowsは数千のリビジョンを経てこれでクロールを開始します。 1.5シャーディングは、リビジョンをそれぞれ1000の個別のフォルダーにグループ化します。 1.6では、古いリビジョンを1つの大きなリビジョンファイルに結合できます。

Answer 2

アップグレードは簡単です。 Subversionは、ほとんどの点で下位互換性があります。ただし、 svnadmin upgrade を使用してリポジトリをアップグレードする必要があります。

これを理解している限り、マージ追跡はアップグレード後のマージに対してのみ機能します。欠落している情報を再構築する実際の方法はありません。

また、 svn-populate-node-origins-index はそのリポジトリで実行する必要がありますが、理由はリンクファイルに記載されています（usage_summaryを参照）。

Answer 3

開発環境によっては、更新されたバインディングが必要になる場合があります。たとえば、Netbeans 6.2はSVN 1.5では機能しません。

Answer 4

リポジトリをsubversion / cvsから完全に異なる種類に変換する多くのツールがあります。議論にならないように一生懸命努力しますが、他のすべてのオプションを見て、たとえば分散バージョン管理システムのように生活を楽にすることができるものがあるかどうかを自分で決めることをお勧めします。 Git は優れていると主張するものです。