Re: Switching away from CVS

[Frank Lichtenheld <djpig@debian.org>]

On Thu, Apr 12, 2007 at 08:38:11PM -0700, Don Armstrong wrote:
> I think that I'm not the only one who really dislikes using CVS; has
> any thought been made to switching away from CVS to something else
> (anything else?)[1]

I would see a real benefit in moving away from CVS. Even if it
works right now, improved usage patterns (e.g. distributed
working, heavy use of branches) can only arise if there
is the technical infrastructure to support them. Not to
speak of the fact that every single operation in CVS is
slow and needs net access...

Nobody should think though that this is an easy task, especially
because of the tight integration of the translation framework into
CVS.

> Perhaps a poll among those who actively commit to the repository would
> be useful to select a replacement?[2]

I think first we should discuss the technical parameters that
influence such a switch. It may be that the list of alternatives
is shorter than we might think...

> I think the viable replacements are (in no particular order):

First let's summarize our needs:

1) We need to be able to somehow port our translation system
   to it. Everyone who is in favor of a particular system
   should at least try to propose a solution for this
   point.
2) It needs to be possible for non-DDs to contribute
   (Alioth should take care of that?)
3) It needs to support some kind of central repository where
   all people can commit (push, whatever) to. (AFAIK, all
   VCS do that, even if it is not normally how they are
   intended to be used. But we need to check that).
4) It should allow some kind of cheap checkout. For regular
    contributors it is certainly ok to have a complete webwml
    checkout lying around, but for some random fix you don't
    want to have to download all that stuff, and especially
    not all the history)
5) Ideally, contributors should be able to contribute from
   a pure etch system. (That requirement may be hard for some
   of the new VCS)

> subversion

Pro:
 - Probably the easiest to migrate to because we can still use the
   keyword method for (1) even though we have to adapt it somehow
 - easier branching and merging than CVS. Still painful compared to
   "new" VCS.
 - allows checkout of random subdirectories
 - Pretty stable from a client POV AFAICT
 - all in all very similar to CVS. Contributors don't have to
   learn much new stuff
Contra:
 - Doesn't really allow for decentralised development. SVK is
   kinda a solution but a hack none-the-less
 - all in all very similar to CVS. Is it really worth the effort?

> git

Pro:
 - I like it and begin to use it heavily :)
 - All in all a very modern VCS, decentralised, very powerful
   branching and merging capabilities
 - Allows at least some kind of cheap checkout ("shallow" checkout
   without the history)
 - AFAICT the backwards compatibility is good compared to some other
   contenders.
 - Someone mentioned git-cvsserver, a program that emulates a
   CVS server, allowing CVS clients access to the git repository.
   It kinda works, but has severe limitations. I have just written
   a detailed analysis about this program for work, I could try
   to translate it into English, if someone is really interested.
Contra:
 - No idea yet how to implement the translation system. We would
   need to go with the SHA1 ids somehow.
 - Doesn't allow sub-checkouts. The ability to split a project
   in several smaller ones (which we could do per language)
   is only in early development
 - As I said, I like it. But ease-of-use is certainly a critical
   point. The early learning curve is steep, very steep.

> bazar

Have not used it in a while, so very few comments
Contra:
 - AFAICT backwards compatibility was very poor in past
   versions. Has that improved?

> mercurial

Don't know it, never used it

> darcs

Have used it but not enough to really comment on it.

> tla

Have not used it in a while, so take my comment with a
grain of salt
Contra:
 - I hated every part of it. One of the worst memories in
   ease-of-use I have...

> but I may have missed some.
> 
> I'm pretty sure tailor is capable of switching to almost all of these
> repository types,[3] so if worst comes to worst, we can revisit the
> decision later, and we won't lose any history.

Hmm, my experiences with trying to import the tla history into the
dpkg SVN are very bad, but it may have improved.

Most VCS also have their own dedicated import programs so one would
need to compare them to tailor before using one.

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/