質問

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

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

管理方法についての私の考えは次のとおりです。

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

これは妥当ですか?私はVSSについて常に悪いことを聞いていますが、これは私にそれらの問題を直接見るように頼んでいるだけですか?

役に立ちましたか?

解決

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)" hg update"を実行しますVSSプロジェクトで、変更を最新の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チェックインを実行するよう注意してください

乾杯、 ルイス

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top