2

現時点では、DVCS を導入する方法を調査しています (特に、Hg と Git を検討しています)。CVS リポジトリを並行して (または CVS プロトコルを介したアクセス メカニズムだけでも) 保持します。ここには、CVS からの切り替えに非常に消極的な開発者もいますが、自動的に同期できるか、CVS プロトコル フロントエンドがあれば、それらを並行して実行しても問題ないはずです。

CVS リポジトリは過去に手動で (ディスク上で) 編集されていましたが、すべてが一貫しているように見え、以前に変換を試すことができ、CVS リポジトリのコピーを移行時の状態で保持することもできます。 .

Git がサポートしていることを考えると、私の考えはgit-cvsserver(1)フロントエンドを実行することでしたが、私はそれについての経験も、事前に行わなければならない実際の変換についても経験がありません。これが全体的に健全な考えであると仮定すると、この移行パスの経験をリストした記事へのポインタを誰でも提供できます。また、そのようなアドバイスを提供する必要がある場合は、潜在的な注意事項を知っておくとよいでしょう。

移行は可能な限りシームレスに行う必要があります。したがって、CVS フロントエンドがその後シームレスに動作する限り、数回の「リハーサル」の後で夜にステージングしても問題ありません。

DVCS のワークフローは最終的に再び中央集権化されますが、古い CVS にはない優れたマージ トラッキングやその他のメカニズムを活用したいと考えています。

4

1 に答える 1

1

git は CVS サーバーを提供しますが、このサーバーは非常に限られています。タグやブランチを作成することはできず、git ブランチは CVS モジュールとして表示されます。また、後でファイル リビジョン番号が同じになるような方法で CVS リポジトリを git に変換することはできません (git cvsserver は、必要なときに各 git ブランチのファイル リビジョンの独自のデータベースを作成します)。

OTOH git を cvs フロントエンドとして使用できます。ワークフローはgit cvsimport、CVS サーバーから履歴を取得するために使用git cvsexportcommitし、いくつかの git コミットをローカルの CVS チェックアウトにエクスポートするために使用します。これについては、ツナさんのブログに詳しい記事があります。

この問題に取り組むもう 1 つの方法は、同僚が転職したがらない理由を分析することです。ここでは、VCS の新しい方法と、常にこの方法で行っていた習慣のどこに行ったかを、彼らは単に知らなかった、または気にかけなかったということです。1 つのパイロット プロジェクトで水銀を使用したことが、他のチーム メンバーを納得させる鍵となりました。

于 2012-11-16T22:24:57.353 に答える