16

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?

Jon Seigel
  • 12,251
  • 8
  • 58
  • 92
WBlasko
  • 2,893
  • 2
  • 17
  • 11
  • The question should be rephrased to a more accurate one: "How to make a good version control system suck?" – Mehrdad Afshari May 01 '09 at 16:03
  • I'm in the same position. But the process you've described sounds worse than using vss by itself :-) – Gabe Moothart May 01 '09 at 16:10
  • I push changes rarely, so it wouldn't be too bad. – WBlasko May 01 '09 at 16:20
  • 1
    @Gabe - I just had a weird thing with VSS where it ate a couple of my files (they are blank now, and it won't bring up any history). So I'll take the hit with the extra work, to protect myself from losing stuff. – mlsteeves Jun 16 '11 at 13:43

1 Answers1

13

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
  • 4,262
  • 6
  • 35
  • 45
  • 1
    Awesome idea. How do you handle VSS bindings in VS? If I remember correctly, those bindings are stored within the solution and project files. So when you work in your "cloned" directory, VS will still think the solution is bound to VSS. – mlsteeves May 16 '11 at 19:04
  • 1
    @mlsteeves: I think if you disable auto-checkout, it will be fine. – Matthew May 31 '11 at 14:17
  • This works, thanks. The only thing that I did differently, is that I keep a Tag called "VSS" that indicates to me where the vss\projectA is at. This way, I can do `hg status --ref xx:yy` (where xx and yy are revision numbers) to get the list of files that have been modified, then only check out those files. – mlsteeves Jun 16 '11 at 13:40
  • @mlsteeves: good idea for the tags. As for the bindings, I haven't yet found them in the VSS repositories that I had to use. – Luis Soeiro Jul 08 '11 at 17:54