16

仕事で Visual Source Safe 2005 を使わざるを得ません。これを DVCS と組み合わせて、バグがある場合やコンパイルできない場合に同僚を混乱させることなくローカルでファイルをチェックインできるようにしたいと考えています。

私の Mercurial での試みでは動作しますが、奇妙な問題がいくつか発生します。つまり、私がチェックアウトしたファイルを他の誰かがチェックアウトしたと考えます。

これをどのように管理すべきかについての私の考えは次のとおりです。

  1. 自動チェックアウトを無効にします。
  2. Mercurial でローカルに作業する
  3. 変更をプッシュする準備ができたら...
    1. Mercurial リポジトリのクローンを作成します。
    2. Visual Source Safe リポジトリを更新する
    3. Mercurial を使用して、2 つのリポジトリをプルしてマージします。
    4. すべてを Visual Source Safe にチェックインします。

これは合理的に聞こえますか？私はいつも VSS について良くないことを耳にします。これは、それらの問題を直接確認するように求めているだけですか?

4

1 に答える 1

13

WBlasko

同じ問題が見つかりました。他の開発者がロックを解除するのを待つのではなく、必要に応じてファイルを変更してマージしたかったのです。私のために働いた解決策は次のとおりです。

1) VSS プロジェクトの最新バージョンを取得します (すべての VSS プロジェクトを vss の下に配置しました)。

c:\vss\projectA

2A) Mercurial で初期化する

cd vss\projectA
C:\vss\projectA>hg init

2B) 自由に変更できる場所にプロジェクトを複製します

hg clone vss\projectA myProjects\projectA

3) VSS コピーから最新の変更を取得します (1 と 2 から来た場合はスキップしてください)

C:\myProjects\projectA>hg pull
C:\myProjects\projectA>hg update
(solve conflicts if any)

4) 複製されたバージョンで自由に作業します。後で、作業を vss コピーにプッシュします。

C:\myProjects\projectA>hg push
(don't run hg update yet, wait for VSS latestes version)

5) ここで、すべてのファイルを VSS プロジェクトにチェックアウトします。

6) VSS プロジェクトで「hg update」を実行して、変更を最新の VSS 変更にマージします。

C:\vss\projectA>hg update
(if there are conflicts, resolve them)

7) 変更をコミットする

C:\vss\projectA>hg commit

8) VSS チェックインを実行します (ロックを他の人に解放します) ステップ 3 に戻ります。ステップ 3 から 8 を永久に繰り返します... ;-)

このようにして、レガシープロジェクトと「対話」しながら、優れたバージョン管理システムを使用できます。また、以下を楽しむこともできます: a) ロックされたファイルは問題ありません b) Hg の使用方法を知っている他のユーザーとリポジトリを共有できます c) ブランチを作成するなど

最初に競合を更新/解決し、テストしてから VSS チェックインを実行するように注意してください

乾杯、ルイス

于 2009-06-04T21:53:43.453 に答える