The problem is that I’d like to be able to use Mercurial, or git, as a front end for development, but have changesets and updates made in Subversion, typically in an integration branch or something that is only written to by a script for Mercurial, or by Hudson when it notices changes. Then our Mercurial repository is updated with changes made by other developers who are using SVN, we pull the changes in and integrate them and test changes before providing new development version, etc.
Does anyone know if the following scenario is possible for development teams with merging & branching? Or if there’s a better way…besides strong arming people to just use one tool?
The following strategy is composed of the following components:
- SVN
- 1-to-1 clone of SVN with Mercurial
- Mercurial Development Repository
In the configuration below, updates would typically be pulled from SVN/trunk into a clone (hgsubversion). The clone would be read-only, and periodically have a script that pulls for changes. The clone would then be cloned into a Development repository, which is read-write (it’s a regular Mercurial Repo). When developers push changes to this developer repository, elements which reside in the Integration branch are pushed into SVN/integration branch. This branch is only committed to by an automated script. If other developers using svn only push changes into SVN’s trunk, they can be pulled into the clone and merged inside Mercurial’s environment. The downside would be that you would lose the visibility at an SVN level where changes came from.
[[[[ trunk [[[[[[[[[[[[[[[[[[[[[[[[ SVN ]]]]]]]]]]]] branch/integration ]]]]]]]]]]]]]]]]]]
| ^
| |
| |
v |
SVN - Mercurial Clone |
| |
| |
| |
v |
Mercurial - Development ---------------------------- Branch - Integration
In courses on using DVCS, that’s actually one of the main use cases I explain, and one that I think shows how deeply awesome DVCSes are…
You have several ways to do it.
Manual way
You SVN/checkout the code, then Hg/init and Hg/commit everything. You then do your work under Hg, commiting small and frequent atomic modifications as you please, locally. When you want to commit back to SVN, you first Hg/up to the Hg revision you made just after the SVN/checkout. You SVN/up, there will be no SVN conflicts because you just updated from a plain SVN revision. You Hg/commit, Hg/merge and then SVN/commit. If someone has commited in SVN meanwhile, you repeat the operation: Hg/up to the last clean SVN revision, SVN/up and Hg/commit+merge.
The way you keep track of the last SVN clean revision is up to you. You could use a tag that you change each time, keep the SVN revisions in a branch or in a separate repository. TIMTOWTDI
Added benefit: this is also a way to serve as an SVN committer for people using Hg, without them being outside version control.
Automatic way
I’ve never used it that way, but tailor is able to do SVN/Hg conversion both ways, repeatedly.