Re: Switching away from CVS
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?)
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
> Perhaps a poll among those who actively commit to the repository would
> be useful to select a replacement?
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
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)
- 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
- 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
- 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?
- 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
- 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.
- 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.
Have not used it in a while, so very few comments
- AFAICT backwards compatibility was very poor in past
versions. Has that improved?
Don't know it, never used it
Have used it but not enough to really comment on it.
Have not used it in a while, so take my comment with a
grain of salt
- 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, 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.
Frank Lichtenheld <firstname.lastname@example.org>