Re: source mgt. requirements solicitation

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Sun, 8 Dec 2002, Tom Lord wrote:

> 	1) There are frequent reports on this list of glitches with
> 	   the current CVS repository.

The most common problem relates to the fileattr performance optimization.  
There are known causes, and a known workaround (remove the cache files 
when the problem occurs).

Other problems (occassional repository corruption) may often relate to
hardware problems.  BK uses extensive checksumming to detect such failures
early (since early detection means backups can more easily be found); the
RCS format has no checksums.  I don't know what svn or arch do here.

There are particular issues that are relevant to GCC (and other CVS users)
that SVN addresses or intends to address as a "better CVS":

* Proper file renaming support.
* Atomic checkins across multiple files (rarely a problem).
* O(1) performance of tag and branch operations.  (A major issue for the 
snapshot script; when the machine is loaded it can take hours to tag the 
tree with the per-snapshot tag, remove the old gcc_latest snapshot tag and 
apply the new one (writing to every ,v file several times).  Part of the 
problem, however, is waiting on locks in each directory, and reducing the 
extent to which locks are needed (e.g. avoiding them for anonymous 
checkouts) and the time for which they are held would help.)
* Performance of operations (checkout, update, ...) on branches (reading 
every file in the tree; the cache mentioned above avoids this problem for 
HEAD only).
* cvs update -d and modules (more an issue with merged gcc and src trees) 
(I don't know whether svn does modules yet).

I haven't seen an obvious need for major changes in branch merging or 
distributed repositories, but people making heavy use of branches may well 
have a use for better tools there.  It's just that something (a) 
supporting file renames and (b) having much better performance (including 
on branches) and (c) having better reliability would solve most of the 
problems for most of the users.  (Not all problems for all users, better 
tools aiming towards that are still useful if they don't cause more 
trouble in the common case.  Checkout, update, diff, annotate, commit 
shouldn't be made any more complicated.)

> 	2) GCC, more than many projects, relies on a distributed
>            testing effort, which mostly applies to the HEAD revision
> 	   and to release candidates.  Most of this testing is done
> 	   by hand.

Better tools are useful here (I always want more testing and more
testcases) but it isn't much to do with version control, rather with
processing the test results into a coherent form (there used to be a
database driven from gcc-testresults) and getting people to fix
regressions they cause (not a problem lately, but there have been long
periods with the regression tester showing regressions staying for weeks).

> 	7) Questions about which patches relate to which issues in the
> 	   issue database are fairly common.

Better tools may help if they encourage volunteers to do the boring task 
of going through incoming bug reports and checking they include enough 
information to reproduce them and can be reproduced.  But that's a matter 
of the long-delayed Bugzilla transition (delayed by human time to set up a 
new machine, not by lack of better version control) possibly linked with 
some system for bug reports to have enough well-defined fields for 
automatic testing.

> 	9) Distributed testing occurs mostly on the HEAD -- which
>            means that the HEAD breaks on various targets, fairly
>            frequently.

It means that HEAD breakage is frequently detected.

> 	11) Some efforts, such as overhauling the build process, will
> 	    probably benefit from a switch to rev ctl. systems that
> 	    support tree rearrangements.

I think it's better to just do renames the CVS way (delete and add) now,
rather than waiting, then when changing make the repository conversion
tool smart enough to handle most of the renames that have taken place in
the GCC repository.

Better tools such as svn or arch may be useful, but we're not CM
developers so it's just a matter of evaluating such tools when they are
ready (do all the common things CVS does just as easily, are reliable
enough, have good enough (preferably better than CVS) performance for what
we do, solve some of the problems with CVS).  Indications (such as above)
of problems with CVS for GCC aren't particularly important, since the main
problems with CVS are well known and affect GCC much as they affect other
projects.

-- 
Joseph S. Myers
jsm28@cam.ac.uk