This is the mail archive of the
mailing list for the GCC project.
Re: Notes from the version control BOF at the summit
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 05 Jun 2004 00:38:39 +0200
- Subject: Re: Notes from the version control BOF at the summit
- References: <firstname.lastname@example.org>
* Ian Lance Taylor:
> * Cheap branches
> In CVS, creating a branch is a slow operation.
You should specify more precisely what you mean by this.
In most new systems, the act of creating a branch is cheap, but
parallel development is still quite expensive in terms of disk space.
(Significantly more expensive than CVS in the case of arch and
Subversion, I believe.)
> * Text search through version history
> The ability to ask which patches changed a particular symbol.
> * Ask who deleted a line
> We can find out who added a line using 'cvs annotate', but it's
> harder to ask who deleted a line.
Should these operations run on the server, or is a client-side
implementation sufficient? The network traffic can be significant for
a client-side implementation (think of someone examining one of the
> * Scale large enough to handle the complete Cygnus/Red Hat development
> This is the largest single repository we know of, with many
> projects, in CVS, dating back to 1991.
I think a similar requirement for working copies is required, too (not
a collection of additional inodes for every file in the working copy,
> * Easily revoke approval
> It would be nice to be able to revoke approval for a patch. Today
> this is done by explicitly reverting the patch.
Isn't it sufficient just to apply the changeset in question in
reverse? Or do you mean something else?
What about an additional requirement that some basic operations must
be very CVS-like?
Joseph also mentioned the ability to edit commit messages afterwards
(which is actually a CVS feature, but it's probably not used right now
because ChangeLogs are the primary reference).
> In general, version control systems break down into centralized
> systems and decentralized systems. CVS is a centralized system. In a
> decentralized system, such as monotone or arch, everybody using the
> system has a complete copy of the repository. While this might
> initially seem an absurd requirement, in fact today's cheap disk
> prices make it feasible. For example, the complete gcc repository
> requires on the order of 2 gigabytes.
Costs of Internet bandwidth might still be an issue, though.
> Now that I've written all that, I don't have any recommendations for
I think the discussion is somewhat premature. Right now, it's not
clear in which directions arch, monotone, and Subversion will develop,
and which system will implement those features that they are missing
according to the list above.
We should certainly revisit this topic in a year or so. The general
picture will be much more clear, and there'll probably a natural
choice by then. (Which one? I really don't know. For example, Aegis
4.17 was released yesterday, and some of the changes point into an
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com,
jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com,
tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.