On Mar 24, 2008, at 4:23 PM, Josh Hursey wrote:
I agree with George and Edgar. I would further add the notion that whatever we decide upon should also work well with MTT. A lot of the support tools for Open MPI are tied to the notion of a continuously increasing 'r' number (MTT, nightly tarballs, Trac?, ...), so we should be careful moving to something that does not have something like that.
Agreed; we need both trac and MTT to work nicely with whatever VCS we use.
I'm also not fully convinced that a switch away from Subversion is necessary. I think I still need to be convinced that the notion of switching isn't a solution looking for a problem. Is Subversion really that bad? How much effort will it take to convert to something new [e.g., change all the support tools, educate all developers, ...]? I think that answers are that Subversion is not really that bad (and may get better in upcoming releases), and it will take quite a lot of work to switch to something else.
I thought that since you have traditionally been a guy working on long- lived branches, you might be eager to get something better than SVN. ;-)
You're certainly right that SVN is "good" as it is. Indeed, Brian and I were the main proponents of switching OMPI from CVS to SVN when SVN hit v1.0 a few years ago (we had the same questions back then: "why is SVN better than CVS?"). SVN v1.5 is supposed to make merging branches much better. I don't know what its timeline is; betas are already available, but it could be anywhere from days to months away (does anyone know for sure?).
As for the distributed-ness aspects of git/hg/bzr, it's kind of a "TiVo thing" -- you can't really understand its goodness until you try it for a while. This is particularly true for those of us -- myself included -- who "grew up" on centralized VCS's; a distributed VCS can seem like insanity!
1. Several of us have been using distributed workarounds to SVN for a while (each of which have their shortcomings): Cisco, Sun, LANL, UTK, Voltaire. We use the distributed aspects for multiple reasons: "gate"ing commits back to the main SVN repo, distributed testing before pushing back to the main repo, development of things not yet ready for the main repo, etc. Having a VCS that is distributed by design (vs. using workarounds) would be quite nice.
2. I've heard statements from other open source projects moving from CVS/SVN/some other centralized VCS to a dVCS along the lines of: "we never knew how much we wanted to branch until it was trivial to do" (SVN made branches easier than CVS; dVCSs make branches easier than SVN).
3. FWIW, Mercurial's basic commands are fairly similar to SVN's (hg update, hg commit, hg log, hg status, ...etc.). As a long-time SVN user, it wasn't hard for me to convert. (I think git's basic commands are pretty similar, too...?)
This switch is not something that I propose lightly. And I'm not pushing for it in the immediate future (indeed, not even before v1.3). We do need to look at how good/bad trac plugins are and how MTT will integrate, etc.
-- Jeff Squyres Cisco Systems
