1

私が解決しようとしている問題は、本番コードと同期していない Subversion と似ていません。Subversion を更新する最も簡単な方法ですが、多少異なります。

(Java) プロジェクトを CVS から SVN に変換しました (cvs2svn を使用し、完全な履歴を保持します) - たとえばバージョン 1.00 で

バージョン 2.00 での開発は、SVN のコードで継続されました。

一方、いくつかの修正は CVS で行われました (開発ツールのセットアップが異なるため)。

次に、プロジェクトの一部を CVS から効果的に再インポートする必要があります。

もしわたしが持っていたら

cvs:project/module1 (version 1.00)
           /module2 (version 1.10)

と

svn:project/trunk/module1 (version 2.xx)
                 /module2 (Version 1.00)

module2 を CVS から再インポートして完全な履歴を保持する方法はありますか?

私は CVS リポジトリで cvs2svn を再度実行し、それを別のプロジェクトとして SVN にロードし、ベースレス マージを実行しようとしていましたが、それがそれほど優れたアイデアであるかどうかはわかりません。

今後、SVN でバージョン 1.xx を維持します。

4

3 に答える 3

0

引用したバージョン番号から、module1 の変換後のコミットはすべて Subversion にあり、module2 の変換後のコミットはすべて CVS にあったようです。その場合は、次のことを試してください。

以前と同じ cvs2svn オプションを使用して、CVS プロジェクト全体を再度変換します。運が良ければ、結果の Subversion リポジトリの r0:rN (N は何らかの数字) が、最初の変換で得られた Subversion リポジトリの重複部分と一致します。この場合、新しい Subversion リポジトリから "svnadmin dump --incremental -rN:HEAD" し、古い Subversion リポジトリの上に "svnadmin load" できるはずです。結合されたリポジトリ内のコミットは時系列順ではありませんが、それはちょっと面倒です (そして、Subversion コミットの番号を付け直すことを犠牲にして、他のツールを使用して修正できる可能性があります)。

(Subversion リポジトリの重複する部分が同一であるとは限りません。cvs2svn はいくつかのヒューリスティックを使用して変更セットを推定しますが、他の変更により推定が異なる場合があります。ただし、各リポジトリに識別可能な「1.00」リビジョンがある限り同じ内容であれば、手順はうまくいくと思います。)

これを試す前にバックアップを作成してください。

于 2010-11-04T16:41:20.123 に答える
0

バージョン 1.xx も SVN で維持する予定であり、コードがどの時点で分岐したかを知っているので、SVN への移行後に作成された変更リストのみをマージできるはずです。これは物事を最もきれいに保つように見えます。

私は現在それを実験しています。

于 2010-10-21T16:35:52.843 に答える
0

現在の CVS リポジトリを新しいダミー SVN リポジトリに変換できます。それを使用して、リビジョンをチェリーピックしてダンプし、それらのダンプを実際の SVN リポジトリに再生することができます。(実際の SVN と CVS/ダミー SVN の両方で同じファイルが変更された場合に、これがどのように対処するかはわかりません。チェリーピックされたダンプを特定のブランチ。）

ただし、より良い方法があるかもしれませんが、これはまったく機能しない可能性があります。私は 1 つの CVS リポジトリを SVN リポジトリに変換しただけで、それは簡単な作業でした。したがって、これを大量の塩で取り、最初にコピーでドライランします.

于 2010-10-21T08:42:41.700 に答える