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:
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.
For corporate legal information go to: