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

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 2

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.