1

The company I work at using SVN now. There are many teams here which has their own repositories for the projects they working on. These repositories sometimes depends on each other (using svn:external) e.g. some end-user-project using core team repo and so on.

I want to move from SVN to Mercurial with my team. I wish to setup workflow like this

  1. Initially clone our current SVN repo into Mercurial, put it to some server and serve it to team members (with hg serve for a first time)
  2. Team members start to work with Mercural only, no direct SVN commits, updates, checkouts. Only push/pull to/from root Mercurial repo (was set up at step 1.).
  3. Eventually (some cron job?) our Mercurial repo is get synced to old SVN server to allow other teams to access our work.

I'm wondering is it ever possible to do this kind of setup? I've already read this article on HgSubversion extension, but it can't give me third step - upstream sync to SVN then changes to Mercurial is came from remote team member.

Olegas
  • 10,349
  • 8
  • 51
  • 72

2 Answers2

1

As you've found out, the main restriction with HgSubversion is that you need to linearize your Mercurial history when pushing it to Subversion. This means that you cannot have branches in your Mercurial history and so it's difficult to work together as a team.

Furthermore, HgSubversion will do a rebase when you push your Mercurial changesets. Imagine that your team is careful to rebase their local commits before pushing to the team Mercurial server. The Mercurial history looks like this:

... r10 --- a1 --- a2 --- b1 --- b2 --- b3

where Alice and Bob have rebased their changesets before pushing them. When you sync with Subversion you get:

... r10 --- a1 --- a2 --- b1 --- b2 --- b3
       \
        r11 --- r12

and HgSubversion will now rebase the Mercurial changesets on top of [r12]:

... r10 --- r11 --- r12 --- a1' --- a2' --- b1' --- b2' --- b3'

Alice and Bob still has the original un-rebased changesets without the primes. So they need to strip before they pull from the team Mercurial server. Such a workflow requires a lot of care to pull off.

I've once setup an easier workflow for a client: instead of rebasing the Mercurial changesets on top of the Subversion revisions, we simply committed the current version of the files to Subversion. That means that we don't preserve the full Mercurial history in the Subversion repository. On the other hand, we can easily deal with merges and whatnot.

In the above example, the SVN server would get a r13 with the state of the Mercurial repository from b3. That r13 revision will be big: it contains all the changes made in a1 to b3. If the people who still use Subversion want to see the individual changes, then they'll have to go look in the Mercurial server — the commit message we put into Subversion has links to the individual changesets in hgweb for Mercurial so it's easy to jump there.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
  • Yeah, I concur. The HgSubversion workflow isn’t suited to teams (even for individuals it is rather uncomfortable). If it’s not objectionable that SVN loses the commit history, it is better to just commit snapshots to SVN (e.g. on a cron job or every time code is pushed). – Laurens Holst Feb 28 '12 at 15:15
  • Martin, Laurens - yes, loosing commit history in SVN after moving to Mercurial is acceptable. I think this solution (bulk SVN commit) is suitable for my case. – Olegas Feb 29 '12 at 06:09
0

I'm wondering is it ever possible to do this kind of setup?

Yes, but can have some troubles in not-so-obvious-cases, which doesn't transparently (and automatically) translated from hg to svn

upstream sync to SVN then changes to Mercurial is came from remote team member

hg push, with svn-repo in path-section. But see above, it will not work always and may require manual rebase before push

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110