[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: source repository

From: Stephen J. Turnbull
Subject: Re: source repository
Date: Wed, 04 Jul 2007 18:13:02 +0900

Nick Roberts writes:

 > It will be a waste if the chosen system becomes unsupported.

Both git and Mercurial are quite mature, and eminently maintainable in
the very unlikely chance that either becomes unsupported.

 > some will sink into oblivion.  While CVS has undoubtedly presented
 > problems, they are small compared to more practical ones such as
 > finding people with the right skills who are willing to work unpaid
 > on Emacs.

Pay is not why I don't work on Emacs (much, directly).  Although
unwillingness to wrestle CVS is not the main reason, I would be *far*
more likely to work on Emacs directly more often if the personal cost
of keeping a repo up-to-date were negligible, and the cost of
communicating a working version of Emacs containing my contributions
to others were small.  How many developers are in this boat, I don't
know.  Can Emacs afford to ignore even one?

 > Personally, I would like to see us change to a distributed system
 > but would prefer to wait until there is one clear candidate.  I
 > guess I could stand one change, but two would be too many.

There will not be one clear candidate for many years, if ever, but
there will nonetheless be no reason to change again project-wide for
quite a while.  As David Kastrup has pointed out, the "d" stands for
"distributed", and therefore there must be a well-defined protocol for
communicating full metadata among repositories.  Neither subversion
nor CVS has that, really, but all of the dSCMs do, and they agree to a
remarkable extent on what the needed metadata is.

This is not just theory; there are already many conversion tools
available, and dSCM being what it is and free software developers
being what they are, the (small) burden of converting to Yet Another
SCM can be amortized over the group of enthusiasts for that SCM.  The
project just continues with whatever it had been using for archival
and distribution purposes.

My personal recommendation at the present time for projects is
Mercurial, because portability issues can be delegated to Guido van
Rossum and the rest of the very capable Python crew.  git is obviously
going to work better on Linux than anywhere else for a while, and it's
not obvious that darcs is going to work well anywhere at the moment.

[1]  Of course this would require some work by FSF legal, but I see no
reason why it would be impossible to write an appropriate assignment
instrument, and enforce it with appropriate commit hooks.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]