views:

414

answers:

1

I'm forced to use Visual Source Safe 2005 at work. I'd like to combine that with a DVCS, so that I can check in files locally without disrupting my co-workers if there's a bug or it doesn't compile.

In my attempts with Mercurial, it works, but causes a few weird issues. Namely, it thinks someone else has checked out the files I have checked out.

Here's my thoughts on how I should manage it:

  1. Disable auto-checkout.
  2. Work locally in Mercurial
  3. When I'm ready to push my changes...
    1. Clone my Mercurial repository.
    2. Update my Visual Source Safe repository
    3. Pull and merge the two repositories using Mercurial.
    4. Check everything into Visual Source Safe.

Does this sound reasonable? I'm always hearing bad things about VSS, is this just asking for me to see those problems firsthand?

+4  A: 

WBlasko

I've found the same problem. I wanted to change files and merge them when needed instead of waiting for some other developer to unlock it. The solution that worked for me was:

1) Get the latest version of a VSS project (I placed all VSS projects under vss):

c:\vss\projectA

2A) Initialize with Mercurial

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

2B) Clone the project to the place where it could be changed at will

hg clone vss\projectA myProjects\projectA

3) Grab the latest changes from the VSS copy (skip if you came from 1 and 2)

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

4) Work at will with the cloned version. Later, push your work to the vss copy:

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

5) Now, perform a checkout of all files to the VSS project

6) Run "hg update" on the VSS project to merge your changes to the latest VSS changes.

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

7) Commit the changes

C:\vss\projectA>hg commit

8) Perform a VSS checkin (releasing the locks to the other folks) Go back to step 3. repeat steps 3-8 forever then... ;-)

This way you can work with a good version control system while still being able "talk" to legacy projects. You will be also be able to enjoy: a) No problem with locked files b) you can share your repository with others that know how to use Hg c) make branches , etc

Just be carefull to first update/solve conflicts, test and then perform VSS checkin

Cheers, Luis

Luis Soeiro