Using Git with Visual Source Safe 6.0

Question

Sorry for this horrid, horrid question.. but there's no way for me to not use VSS.

I would like to be able to use Git locally for branch development, etc. while using Visual Source Safe 6. My knowledge of all of the ins and outs of Git is limited at the moment, as I'm a recent convert.

Question:
What I would like to be able to do is work within a Git repository. I would like to do this and get all of the goodies that this will allow with branching, etc. At the end of my day, or at other needed moments I would like to be able to take whatever work I'm doing and place it into the master repository which I would then place into VSS.

Ideally, at the start of the work day I would get VSS latest version.. commit this to Git.. then work on an alternate branch, putting the changes back into master when I needed to commit to VSS.

Being that I am a relative git newbie, what might be the best way to accomplish this.. along with the best commands to issue/way to set this up.

*note: Source Safe needs the file checked out before changes can be made to it I think. Maybe there is some tool / script I can use to help automate this for pushing changes back into VSS ?

Augustinaaugustine

I know it stinks. I'm just looking for the easiest way to do this and keep a nice Git repo, and push my changes back into VSS at intervals. – Augustinaaugustine

+1. I feel the same pain every day :( Why on Earth was VSS ever invented ? – Compile

Answer 1

The setup you're considering should work fine. For git commands just check the tutorials.

The workflow I've used (not with VSS, but the concept is the same) is something like:

• Checkout from main (i.e. VSS)
• Keep one "trunk" branch that is in sync with VSS
  • will always be kept clean
• Develop in branches branched from "trunk"
• Updating from VSS:
  • switch to "trunk"
  • update with VSS
  • git commit the changes
  • rebase the branches that are branched from trunk
• To push changes to VSS:
  • push changes from the development branch to "trunk"
  • switch to "trunk"
  • VSS commit the changes

Nearsighted

How would I get around the VSS need to have files checked out so that it knows what to commit.. and on the same token, those files that are added ? – Augustinaaugustine

hmm, you're right, tough one (I wasn't thinking VSS specifically). I would probably write a script that looks at the files changed since the last sync (modified / added / deleted) and does the appropriately add/checkout/delete through the command-line VSS interface. – Nearsighted

I think you're right. To do this 'right' I'll have to build some scripts to take care of these things. Definitely going to be a challenge. – Augustinaaugustine

if you are certain no-one else has changed anything you can get away with checking out the entire project without replacing your local copies and check everything back in. If there is a possibility for someone else to have changed something you'r working on, you should checkout everything at the start of the day, do your work and checkin at the end of the day to make sure you never overwrite someone elses work. – Cravens

I'd be very interested if you get the script working! As our company uses VSS to! dumb arses. PM me if you get anywhere! cheers. Ian – Placer

BTW - someone put up their workflow with Mercurial and VSS, could work similarly with git. Basically, checks out all files in VSS for the commit. #812499 – Nearsighted

Answer 2

Anyone stuck with VSS may find the following post useful if you have to deal with branches:

http://timwise.blogspot.com/2011/11/multiple-working-folders-for-git-on.html

It basically details using SysInternals' Junction to get symlink support in Windows and then sharing a git repo between the physical branch folders that VSS forces on you by copying the files in the .git folder, and sym-linking the folders.

And here are the scripts for automating the sharing

• https://gist.github.com/1373136 - create
• https://gist.github.com/1373142 - remove

Confectionery

Answer 3

I am also caught in this, the way I do it is to not have others touch my VSS and have all the files checked out all the time, this means noone else can contribute, so this is naturally not a viable solution for everyone. The solution I would suggest is that you:

• Chekout from VSS
• Create a branch to work on your feature
• finish work on your feature
• Switch to Master branch
• Update latest VSS
  • If any changes are done, rebase your branch
• See what files are changed using $ git diff --name-status master..branchName ( see Showing which files have changed between two revisions for the source of this )
• Check out the altered files using VSS
• Merge your branch onto master ( preferably deleting your feature branch )
• Commit to VSS

Some of these you might be able to script your way out of, but since you are most probably using M$ (since you are using VSS) this is not something I can help you with.

The way VSS works I would think that it would be better to minimize the time spent with the files checked out of VSS and therefore that this is a better way.

Be advised, there may be some problems updating the files, as VSS automagically sets the readonly flag on files that are not checked out. A workaround might be needed here.

Tala