Multiple simultaneous version control systems?

Question

I'm relatively new to version control, and so far only have experience working with Subversion using TortoiseSVN/VisualSVN. I've been reading about other types of VCS (git, mercurial, etc), and am considering trying them out - however, many of the arguments for or against a particular VCS seem like they largely come down to subjective preference, so I'll probably wind up giving each one a look.

In thinking about doing so, I was wondering if it was even theoretically possible to use multiple VCS on a single codebase. Which (if any) combinations of VCS might this be a possibility for? And if possible, how much of a logistical nightmare would it be trying to juggle the respective exclusion lists?

One possible argument for doing so could be backup redundancy. Several VCS providers (Beanstalk, Github, Bitbucket) offer one free repository, so you could have the same repo backed up for free in several different places.

Answer 1

It's usually difficult (but not impossible) to handle multiple VCS on one codebase. However, you'll potentially run into problems with deletion of files... Sometimes, one VC will not realize a file has been deleted.

However, I don't recommend this. Most VC use files within the codebase to track changes. Having multiple VC systems in place will pollute your file system with lots of files that will potentially cause issues in the other VCs.

Answer 2

Certainly, this is possible, even commonplace in some cases. For example, git and svn are a natural pair for this. The standard use case is an organization which must have a legacy central Subversion repository for various reasons, but in which the developers want to use Git for the productivity boost it provides.

Enter git-svn. Now the developers push and pull from their own local Git repos to the central Subversion repository, but still get all the cool power of Git. This process is completely and totally transparent to the Subversion repository, which simply sees the changes that get pushed to it.

Answer 3

I know it's not quite using multiple VCSs, but it's possible for some VCSs to have different front ends. Git, for example, can have an SVN front end so that SVN clients can use the Git repository (and they'll be none the wiser that it's Git). I think there are also other front ends available for it.

Answer 4

Mercurial (with hgsubversion), git (with git-svn) and bzr (bzr-svn) all have an option to synchronize with an upstream svn repository.

So it's already possible (assuming the extensions work well enough) to interact with an svn repository with differents SCM.

Answer 5

It is certainly possible to do this. I use git-svn to update my local git repository and commit to the corporate svn repository. With any VCS tool that you will decide to use, the problem that you will most likely to encounter is during updating your local repository with the changes from the remote repository.

If you use bazaar for your local repository, the most problematic thing is when your local bazaar repository is diverged and you want to commit to your remote repository. Sometimes you have to do "push overwrite" to resolve it.

I don't experience this "diverged repository problem" when using git-svn to update my local git repository with the changes from the remote svn repository. But sometimes when I do "git svn rebase" it will have conflicts and if not doing the procedure to resolve it the right, you can spend alot of time. Because I have encountered this over and over again, I have documented it and I don't find it such a big deal now.

Answer 6

My first response when I read your question was, "Sure, technically possible, but a really really bad idea."

I'll backtrack a little after seeing the other comments. Okay, each user could have a local repository separate from the central repository, and use this to basically keep checkpoints as he works. In that case they could be completely separate VCSs and it wouldn't matter.

But if you're thinking of two different VCSs simultaneously holding your central repository, that's techincally possible, but a really really bad idea. The whole point of a VCS is that you maintain a history of all the changes made to the files, that you can see what changes were made when and -- if users include half-way decent comments on commits -- why. If a customer who has the June 19, 2007 version has a problem, you can retrieve the code exactly as it existed on June 19, 2007, so you're debugging the code that the user is actually running. If you discover that the latest change was a big mistake you can roll back. Etc etc.

But if you have two repositories ... Are you going to do every commit identically to both repositories? At the least that's a bunch of extra work. At worst, sooner or later somebody is going to make a mistake, forget to commit to one or not commit until the next day after someone else had made an intervening commit, and the repositories won't really be identical. Or are you going to alternate, sometimes checking out of A and sometimes out of B? But then no one will ever know what's in either one.

I could see using two different VCSs for a few days or a few weeks just to try them out and see how they work, get a feel for which you like better. But even at that, I wouldn't do that as my production system. I'd have the real production VCS, and then the other one on the side that we play with but nobody treats as authoritative.