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.
> 
> "Cheap branches" covers more than just branch creation time.

True.  I explained what I meant in the text, but I should have said
"fast branches," not "cheap branches."  Likewise for tags.


> >> > * 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.
> 
> Then the requirement is quite meaningless because it's just an issue
> of a client-side script if there aren't any efficiency concerns.

I didn't say that there were no efficiency concerns.  I said that
where the operation should run depends on which version control system
is being used.  With CVS, the operation would have to run on the
server.  With monotone, the operation would most likely run on the
client.


> > 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.
> 
> I think the limit should be at one inode per file (including all
> metadata), and at most a dozen per directory.

OK.


> >> What about an additional requirement that some basic operations must
> >> be very CVS-like?
> >
> > Why should there be such a requirement?
> 
> It would make migration easier and could mean that existing shell
> scripts are more easily adopted.

That would be nice, but I personally don't think it should be a
requirement.


> >> 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.
> 
> Well, the funder's goal and the GCC teams's do not necessarily have to
> match.

I suppose I explained the situation poorly.  Graydon was at the gcc
summit.  He asked for the version BOF to occur.  He explicitly asked
for guidance in further development.  He was open to the possibility
of doing work on a system other than monotone.

Ian