More SVN->HG questions

[Jeff Squyres]

Thanks for your continued patience with my questions of converting a  
goodly-sized project from SVN to Mercurial.  Today, we have some  
questions about typical workflow using Mercurial between a large set  
of physically disparate developers (all of whom are coming from a  
long, strong SVN background).

1. When we use the convert extension to convert SVN->HG, something  
like this:

     hg convert --config convert.hg.clonebranches=true \
         -A username-map.txt /path/to/svnroot

We get a directory with a "default" clone and a separate clone for  
each SVN /branches directory.  So far so good.

Our question is: how do you work with these repositories after the  
conversion?  Specifically, we are used to committing a change (or  
series of changes) to the SVN trunk and then svn merge'ing from the  
trunk to our release branch(es).  We were expecting to use a similar  
kind of workflow: pushing changes from the "default" Mercurial repo to  
our release Mercurial repo(s).

Using a test set of "hg convert"ed clones, I made a trivial commit on  
the "default" HG repo and then tried to pull it over to the "v1.3"  
clone:

-----
cd ...../default
echo new file > foo
hg add foo
hg ci foo -m "new file"
hg log | head
    # ---> see that it was r12345
cd ../v1.3
hg pull ../default -r 12345
-----

This ends up pulling a lot of changesets and making a new head in the  
v1.3 repo -- not quite what I intended.

How do you push/pull single r numbers from "default" to "v1.3"?  Or is  
the assumption of using an SVN-like workflow here a mistake -- should  
we be doing something different?

2. With a distributed system like Mercurial, we're anticipating that a  
bunch of our developers will have private / internal repositories  
where they do their main development, potentially pulling down from  
the central trunk/default HG repo over time, etc.  And then pushing  
back up to trunk/default when they're ready.

Indeed, several of us are using workflows like this, but the final  
"push" upstream is an SVN commit -- so all the HG history is lost.   
This actually works out fairly well, because we don't want all the  
intermediate commits, merges, etc. to go upstream.  Specifically, we  
find that we have lots of "throwaway" commits in our internal  
repositories -- committing just to backup, or to push to a different  
(internal) system to test, etc.  Hence, we have lots more commits than  
are really necessary to go back to the official trunk/default HG  
repository.  Not only will all these extra commits "pollute" the  
common repository that we all share, it will also make moving commits  
to release repositories much more difficult (because instead of moving  
1 commit, you have to move N commits, and they may be deeply  
intertwined in history).

How to other projects typically handle this kind of scenario?  Do your  
developers use the rebase extension, or mq?  Or do you do something  
else?

Any workflow advice that other multi-person projects have would be  
helpful.

Thanks for your time!

-- 
Jeff Squyres
Cisco Systems