Re: Locking support

[James Youngman]

"Noel L Yap" <address@hidden> writes:

> I think it would be much easier to have them use "cvs edit -c" as is
> (put "edit -c" in their ~/.cvsrc files).  In the future, you may
> convince them to try out "cvs edit -f" when the need arises (eg
> someone left did a "cvs edit" then went on vacation).

Heh; the number of times I have had to _carefully_ break SCCS locks.  

> I originally created these patches for users who were also used to
> locks (PVCS and RCS), but by the time I finished the patches, they
> were so used to the concurrency in CVS that they never used them.  

My experience too is that once the developers take the plunge they
don't miss the exclusive locking feature.  

I kept stats for one project; in about 250 man-days of effort 7.5
hours a day, full-time (i.e. no other work going on except this) by 9
developers on 50 core files (and about 2000 other mostly-read-only
files[1]), we have conflicts on exactly two occasions.

[1] The other files were the Tcl and Tk distributions, plus a gutted
version of xterm (no X!) which was used to build a full-screen VT220
(ish) equivalent of Expect.


> I still think a good process would include use of the patches to
> support more confidence in concurrent development.

My initial reaction is that either your process works, or you
developers need training, or your process needs changing.  But I guess
there's room for a fourth option, "You're using the wrong tools".

-- 
James Youngman
Manchester, UK.  +44 161 226 7339
PGP (GPG) key ID for <address@hidden> is 64A95EE5 (F1B83152).