Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] Switching away from SVN?
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-03-24 16:49:50

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