Re: Notes from the version control BOF at the summit

[Ian Lance Taylor <ian at wasabisystems dot com>]

Florian Weimer <fw@deneb.enyo.de> writes:

> > * Cheap branches
> >     In CVS, creating a branch is a slow operation.
> 
> You should specify more precisely what you mean by this.

It seems reasonably clear to me.  I mean that
    cvs tag -b branchname gcc
takes a long time.

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

If the space required scales in terms of the number of files which are
modified, then I think this is reasonable.

The time required to make a CVS branch scales in terms of the number
of files which are in the repository, which in the normal case is a
much larger number.

> > * 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
> ChangeLog files).

The correct answer would seem to depend entirely upon which version
control system is being used, and the relevant tradeoffs.  I don't
think there should be any particular requirement that the operation
run in any particular place.

> > * Scale large enough to handle the complete Cygnus/Red Hat development
> >   repository
> >     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,
> for example).

I suppose there should be some limit, but I'm not sure how to express
it.  Any normal system would seem to require at least one inode per
file in the working directory.

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

That is one way to do this, yes.  In CVS this is a somewhat awkward
operation involving generating a diff and running patch.

> What about an additional requirement that some basic operations must
> be very CVS-like?

Why should there be such a requirement?

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

That is reasonable.

> > Now that I've written all that, I don't have any recommendations for
> > action.
> 
> 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.

But as I said, Graydon has funding right now to do development.  In
general we should think about what we want, in order to guide people
doing development.

> 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
> interesting direction.)

If that is the consensus, that would be perfectly reasonable.

Ian