"Limited resources"??? Disk space is practically free these days! Last week's
local ads had a 27GB disk for $150; that's about $5 per gigabyte. Since your
source code is unlikely to be over a gigabyte, each developer could have several
working directories for $5 each - probably a big savings compared to the time
you are losing in trying to squeeze together in a "limited resource"
environment. I bet you're losing (at least) 3-5 hours/week in lost
productivity. Multiply that by your pay rate (including benefits) and you can
probably make up the $5 with just a few minutes saved work time. You and your
co-workers are worth a lot more than cheap computer hardware - don't limit
yourselves that way.
Alan Thompson
"laine+info-cvs"@laine.org (Laine Stump) on 07/25/2000 12:47:28 PM
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
cc: (bcc: Alan Thompson/Orincon)
Subject: Re: CVS scenario -- who "owns" a working directory?
Larry Jones writes:
> Yuck! How do you prevent two people from telnetting in to the same
> workstation and stepping on each other's changes? CVS was never
> intended to handle that kind of an environment. About the only thing I
> can suggest is always doing ``cvs -d $CVSROOT'' to override CVS/Root.
Although it's obviously fraught with perils, and I would never *want* to
do it, I've been forced to share work directories between 3 or 4 people in
the past, due to limited resources on the machine in question. While it
did cause inconvenience and frustration at times (eg, somebody is
halfway through making a change in some other directory and you try to
do a "make all" which fails because of syntax errors in their
not-yet-completed code), it is at least marginally workable in a pinch.
Very definitely if there is enough space, having separate work
directories is a much better answer. If there's not enough local disk
space, how about having each user NFS-mount their work directory from
somewhere else? (that would also allow you to run cvs itself on another
machine (the NFS server), thus removing that burden from this apparently
minimal target machine.)
