It came up on the call today, so I thought I'd throw out some references here
on the list...
A while ago, we investigated moving the OMPI development away from SVN and to a
100% Mercurial solution. We ended up not doing this for a few reasons:
1. We actually kinda like the combo SVN+Mercurial solution that we use now. A
bunch of us OMPI developers use variants on "combo" schemes, the most common of
which we documented on the wiki:
https://svn.open-mpi.org/trac/ompi/wiki/UsingMercurial
2. Perhaps we're reflecting our CVS/SVN backgrounds, but we didn't like the
fact that if you do a bunch of "private" commits internally, when you push your
final set of changes back up to the public mainline, all those private commits
are listed. Instead, we tend to prefer to make bunches of short-lived branches
off the OMPI public mainline, do a bunch of private development, and then bring
that functionality back to the OMPI mainline in a (series of) public commits.
There's no need to show all the internal "just committing so that I can
synchronize to another cluster" kinds of commits.
That being said, there are actually (at least) two ways to avoid exposing these
kinds of internal commits: mercurial queues and rebasing. But we didn't think
the OMPI developer community would be wild about these options. We could be
wrong, of course, but that was our assessment at the time.
-----
So there ya go. :-) We still love Mercurial and use it every day, but we've
been fairly happy with our SVN+Mercurial solutions.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
