異なる分散バージョン管理システムが連携して動作する

Question

私のオフィスには、ソース管理に使用する中央の Source Safe 2005 がインストールされています。オフィスがサーバー上で使用するものを変更することはできません。

私はラップトップで開発しており、中央プロバイダーが何であるかに関係なく、中央サーバー (利用可能な場合) と同期できる別のローカル ソース管理リポジトリを持ちたいと考えています。リクエストの理由は、炎上のフープを飛び越えることなく開発を続けながら、クライアントのプレゼンテーション用にローカルの安定したブランチ/ビルドを維持できるようにするためです。また、コンサルタントとして、クライアントがソース コントロール プロバイダーの使用を要求する場合がありますが、ここでの柔軟性があれば作業が楽になります。

既存の分散ソース管理クライアントはこれを処理できますか?

Answer 1

良い...カーネルトラップには これについて何か. 。使えるみたいですね vss2svn Source Safe リポジトリを Subversion リポジトリにパイプしてから、非常に優れた git-svn を使用してローカル git リポジトリにプルします。

この方法を使用した場合、VSS へのコミットはスムーズで自動プロセスではないと思われます。

Answer 2

コードの現在のバージョンをチェックアウトして、それを中心に git リポジトリを作成できるはずです。それを更新してローカル git リポジトリにコミットするのは簡単なはずです。クローンを作成する必要があります。

唯一の問題は、適切な無視ファイルをいじって、両方がお互いを無視するようにする必要があることです（私はSVNで同様のことを行いました）。SourceSafe を使用すると、物事を無視できるようになると思います。また、特定の操作を 2 回実行する必要があります (ファイルを削除していることを両方に伝えるなど)。

Answer 3

これ HanselMinutes のエピソードは、まさに私が聞きたかったことをカバーしています。どうやら Git はローカルで使用でき、必要に応じて外部の Subversion/vss リポジトリにアタッチできます。彼らはそれについて14〜15分間話します。

Answer 4

いつか、私は VSS を使用する会社 (およびその他のあまり知られていない VSS を使用する他の会社) で働きます。 SCM）しかし、私と私のグループにとって、アクティブな開発にはSVN（いつかGITを試してみる）を使用することを好みます。

まず、この状況では、VSS へのコミットが月に数回しかない場合にのみ良い考えです。これは、(VSS 以外の) 他の SCM を使用すると柔軟性が高まりますが、SVN から VSS へのコミットは時間の経過とともにコストがかかるためです。

私の解決策は次のとおりです。

VSS -> SVN:VSS の現在の更新ディレクトリ作業を現在の SVN にコピーし、SVN クライアントを更新して SVN に更新/マージ/コミットする Linux スクリプト (または Ant スクリプト、または XXX スクリプト) があります。これにより、VSS を使用する会社の残りの部分の変更から更新されます。

SVN -> VSS:この方法では、すべての変更ファイルを VSS にチェックアウトする必要があります。その後、リバース スクリプトを使用して、現在の更新 SVN ディレクトリからコピーし (.svn ディレクトリを無視)、現在の更新 VSS ディレクトリにコピーし、更新してコミットするだけです。

ただし、場合によっては、時間をかけてこれを行う価値があることを覚えておいてください。