This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Notes from the version control BOF at the summit
* Ian Lance Taylor:
> 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.
> 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.
Of course this is true, but you also have to look at the disk space
requirements. CVS and Subversion have quite different behavior in
this area, for example.
>> > * 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 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.
>> > * 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.
Huh? You can use "cvs update" to apply changes in reverse, revoking
them. The trouble is, of course, figuring out the changes to revert
because CVS doesn't now anything about changesets.
>> 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.
>> > 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.
Well, the funder's goal and the GCC teams's do not necessarily have to
match.
> In general we should think about what we want, in order to guide
> people doing development.
This is a reasonable position if there is a chance that there is
actually a SCM system whose developers are willing (and able) to
invest the necessary resources to fit it to the GCC project. However,
I don't think that there is such a SCM system right now.
--
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.