Different Distributed Version Control Systems working together

Question

My office has a central Source Safe 2005 install that we use for source control. I can't change what the office uses on the server.

I develop on a laptop and would like to have a different local source control repository that can sync with the central server (when available) regardless of the what that central provider is. The reason for the request is so I can maintain a local stable branch/build for client presentations while continuing to develop without having to jump through flaming hoops. Also, as a consultant, my clients may request that I use their source control provider and flexibility here would make life easier.

Can any of the existing distributed source control clients handle that?

Answer 1

You should be able to check out the current version of the code and then create a git repository around it. Updating that and committing it to your local git repository should be painless. As should cloning it.

The only catch is that you need to have them both ignore each other (I've done something similar with SVN) by messing with the appropriate ignore files. I'm presuming SourceSafe let's you ignore things. And you'll need to do certain operations twice (like telling both that you are deleting a file).

Answer 2

Well... KernelTrap has something on this. Looks like you can use vss2svn to pipe the Source Safe repo into a Subversion repository, then use the very nice git-svn to pull into a local git repo.

I would assume the commits back to VSS would not be a smooth, automatic process using this method.

Answer 3

Hi, some day i work in a company that use VSS (and in other companies that use other less unknow SCM) but i prefer use SVN (someday i'll try GIT) for active development, for me and my group.

First of all, this situation it's only good idea, if commit to VSS are few over month, because working with other SCM (than VSS) give you more flexiblity, but commint to VSS from SVN is expensive in time.

My solution was:

VSS -> SVN: I have linux script (or ant script, or XXX script) that copy from currrent update directory work of VSS to current SVN, then refresh SVN client and update/merge/commit to SVN. With this, you are update from changes of the rest of company that use VSS.

SVN -> VSS: In this way, you need a checkout of all your modify files to VSS, then you can simply use the reverse script to copy from current update SVN directory (ignore .svn directories) and copy to current update VSS directory, update and commit.

But remember, in a few case does worth your time to do this.

Answer 4

This episode of HanselMinutes covers exactly what I was hoping to hear. Apparently Git can be used locally then attached to external subversion/vss repositories as need. They talk about it 14 ~ 15 minutes in.