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
> 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
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
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.