How source control management interworking can be achieved?

Question

While related questions have been asked before I would like to see an idea about how interoperability between two source control management (SCM) systems can be done. For example we could consider any SCM out there (Mercurial, Git, SVN, CVS, Perforce, ClearCase ...).

Mainly I'm interested if ClearCase can be used along with SVN or Git/Mercurial.

How can I have a remote ClearCase maintained source tree maintained by another SCM also (beside ClearCase)?

While others can use ClearCase we would like to use the 'other' SCM and commit changes in that repository. Changes in ClearCase repository should follow shortly or periodically (and also updating from ClearCase repository should be periodically in order to make sure we're having the latest sources)

Any (others/related) examples/experiences are welcome. Thanks !

PS: This is not about dumping ClearCase (I would do that gladly), it's about working with two source controls at the same time on the same source tree.

Answer 1

one thing that comes to my mind is git-svn: "It provides a bidirectional flow of changes between a Subversion and a git repository."

Answer 2

As long as you can make others SCM ignore eachothers (through a .cvsignore/.hgignore kind of file) or make them cooperate (like git svn), I do not see why you should not be able to do that. I already do through svn/Hg/git and CVS.

Answer 3

In a very generic way, you can always commit the current HEAD of the "foreign" (ClearCase in your case) repo into a git branch, rebase your own branch on top of that and commit the result back into the "foreign" repo. Lather, rinse, repeat.

Answer 4

I really recommend against mixing them. Managing one SCM is a complex enough task that you don't want regular user to have to deal with several of them.

If you still want to mix, distributed SCM like Mercurial or git have something nice, which is the ability to use them without imposing them on anybody. Each developer / team can manage his local copy / local branch in git or mercurial with nobody aware of it.

git + subversion or mercurial + subversion have the advantage that pushing back to main repository is part of the tool, but one can live without it.

In your case, looks like ClearCase is forced on you but you want to use an alternative. You can decide to use git in your team, and regularly push the main branch to ClearCase.

Answer 5

The problem with interoperability between two source control management (SCM) is if one SCM has richer model than other (for example Subversion prior to 1.5.0 didn't store all parents of a merge if you didn't use either svnmerge or SVK, while most modern SCM remember merges; Mercurial doesn't support octopus merges i.e. merges with more than two parents).

There are at least few different kinds of solutions I know about:

• generic SCM interoperability solution, like fast-import exchange standard created in Git but supported by Bazaar and I think also by Mercurial, or tools such as Tailor (but Tailor has its limitation)
• specific tools, which use either SCM API or SCM scriptability, like git-svn between Git and Subversion (uses Subversion Perl API) or git-p4 between Git and Perforce
• by hand i.e. using common working area (working directory) getting changes (checking out) from one SCM and adding changes (comitting) to other SCM. This would require setting up appropriate ignore files, so one SCM ignores other SCM specific helper files and directories.
• server emulation in the case of interaction between centralized SCM (like CVS) and other SCM (like Git) by emulating server for centralized SCM, but having repository in other SCM, like git-svnserver does
• data backend where one SCM (like Bazaar or Darcs) store changes (data) in repository in other SCM format. I don't know example for such solution.

Answer 6

I agree with BlueBird75: mixing two different referential is not a good idea, for the same reason it is not a good idea to have several databases with the same kind of information. Synchronization and duplication are not easy to manage in those cases.

We do "publish" some data managed in our ClearCase repositories (VOBs) to other VCS (Subversion, Perforce, ...) or repositories (like Maven), for other teams which do not use ClearCase. However, the data exported are only deliveries.

A "delivery unit" is a small ('small' as in the fewest number of files as possible) set of packaged files: jar, war and ear are all an example of such packaged files, but we also include sources (compressed in a zip file), javadoc (compressed also), script to execute this delivery, and so on.

That way, only a few files are exported to clients, and only when a delivery is build and represent a significant stable version.