0

私の意見では、SVN には CVS よりも多くの利点がありますが、レガシー システムとチームを 10 年以上使用されているものから移行するのは難しいことがわかります。

なぜ SVN に移行する必要があるのか​​を説明するときに尋ねられるであろう質問をもう一度推測しようとしていますが、適切な回答を記入していただけないでしょうか (または、SVN がこれよりも悪い理由でさえ)。

また、現在の作業方法についても説明しようと思います。何を変更する必要があるか教えていただければ幸いです。

現在、CVS、HEAD (本番)、およびテスト ( TEST)の主要なセクションを作成する必要があります。

TEST からのコードは毎晩ビルドされ、ビルドが成功すると、新しい CVS タグでタグ付けされます。満足したら、そのタグを TEST から HEAD にプルし、最終的なビルドを作成してユーザーにデプロイします。

私たちは CVS の $Header$ 機能を広く使用していますが、これはコードとのマージ (特にリバース マージ) の際に衝突を引き起こすことがよくあります。

CVS はファイルを個別に処理するため、破損したコミットをロールバックする (またはファイルが変更されたことを確認することさえ) ことは非常に困難です (ファイルごとに)。

チェックイン時に、CVS は、あなたが近づいていない多くのファイルに触れたと考える傾向があります。

要約すると、SVN への変更は私たちにどのような影響を与えるのでしょうか?

御時間ありがとうございます、

4

1 に答える 1

1

私たちは CVS の $Header$ 機能を広く使用していますが、これはコードとのマージ (特にリバース マージ) の際に衝突を引き起こすことがよくあります。

Subversion は、マージと差分を実行する際に展開されたキーワードを無視するほどスマートです。

CVS はファイルを個別に処理するため、壊れたコミットをロールバックする (またはファイルが変更されたことを確認することさえ) ことは非常に困難です (ファイルごとに)。

Subversion のリビジョンがどのように保存/コミットされるかにより、実際には、単一のコミット (またはコミットのグループ) から個々の項目を選んでロールバックするよりも、コミット全体 (リビジョン) をロールバックする方が簡単です。http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undoを参照してください。

チェックイン時に、CVS は、あなたが近づいていない多くのファイルに触れたと考える傾向があります。

Subversion でこれを見たことがあるとは言えません。最終変更時刻が変更されたために CVS が変更を取得しているのに、ファイルの内容が変更されていないのではないでしょうか? Subversion は、ファイルの mtime を使用して変更が発生した可能性があるかどうかを判断し、現在のコピーとリポジトリから最後に取得した元のコピーとの間で MD5 比較を実行します。mtimes が一致しないが MD5 が一致する場合、変更としてフラグが立てられません。

于 2012-10-02T18:57:27.990 に答える