Some thoughts on CVS

[sml13 cornell edu]

Ok, I'm still technically a newbie, so perhaps it is way out of place for 
me to make comments like this (to my credit, I have done some development 
now with GTK+ -- little things on my own -- but I have not contributed 
any code (YET!) to gnome proper).

BUT, this CVS thing is problemmatic.  I have been looking over some CVS 
documentation that I have found on the web (Per Cederqvist et al's 1.10-2
manual, among others) and have some thoughts on this whole 'broken CVS' 
issue.  It seems from the reading that I have done that it is customary 
in projects under CVS control for someone wishing to do a commit of 
his/her code to the tree to do a 'cvs update' on the whole tree to bring 
down any changes that others have made to the repository, integrate them 
into one's 
own changes locally, compile locally, and then test it locally to make sure 
there aren't any 
conflicts with other changes made since one updated from the repository 
tree, all BEFORE doing the actual commit of one's changes.  This is 
how it is "supposed" to work, right?  But, apparently CVS has a bug 
(maybe we could pause Gnome development for a second -- yeah, right -- 
and take care of this onerous little glitch) that prevents it from 
recognizing 'virtual' sub-modules (am I understanding this correctly?).  
So, everyone is doing 'cvs checkout's instead of 'cvs update's, perhaps not 
updating and 
testing before committing to avoid this bug.  Well, this seems to lead to 
a broken CVS tree much of the time (these last few days at least).  Now, 
understand that there is no way, of course, to prevent the 
synchronization issue when one 
tests ones changes against the current tree, but, darnit, the "current" 
tree has been updated by someone else before you could get your new stuff 
up to the CVS repository after testing it (with a project this big, I get 
that happens A LOT).  But, I think that is unavoidable (no?).

My suggestion:  Why don't we use Mozilla.org's Tinderbox to keep an eye 
on these CVS-breaking events so that people don't spend time (and eat up 
bandwidth on the server) trying to download a tree that is up in flames 
anyway.  This would also just be a good way to keep track of the 
stability of the project.  Needless to say, though, this would require a 
dedicated machine (most likely) to do constant builds.  I know what your 
next question is, and, no, my little AMD K6-233Mhz with 64M SDRAM (and a 
hard-drive bursting at the seams) is not up to the task :-)  But, I think 
it might be worth considering, discussing, etc.

my $0.02

shane