info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS - setup reserved checkout


From: Kaz Kylheku
Subject: Re: CVS - setup reserved checkout
Date: Mon, 29 Oct 2001 23:28:52 GMT
User-agent: slrn/0.9.6.3 (Linux)

In article <address@hidden>, Greg Cooper wrote:
>David Masterson <address@hidden> wrote in message news:<address@hidden>...
>> >>>>> Andrew  writes:
>>  
>> > Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix
>> > (Solaris)? Or is there any documentation on this other than the
>> > manual that comes with the source code?
>> 
>> Given the CVS model of unreserved checkouts, why do you need reserved
>> checkouts?  Also, are you talking about reserved checkouts of a file
>> or an entire product?
>
>We use CVS (ver 1.11) and we like the unreserved checkout model, but

The what model? You seem to still be clinging to the biased terminology
used by the vendors of inferior version control tools. ``Unreserved''
is a negative word that suggests risk and hassle, like an
unreserved airplane ticket, restaurant table or hotel room.

>the manager of a different project here wants to use our repository
>only if we can enforce reserved checkouts on a per-file basis (they
>don't want to use watches).  Is it possible (and manageable) to make
>CVS do this?

Tell the manager to shed his or her superstitions, and work with
the facts. The facts are:

- Concurrent development works just fine.
- Your team already likes it.
- Strict locking does not prevent concurrency, it only reduces
  it to a coarse granularity: coarse enough to interfere with
  productivity, but not coarse enough to eradicate conflicts.
  To eliminate conflicts, you have to lock the entire repository
  so that only one developer at a time can do anything on the
  software base as a whole.

Since it is already working for you, you can invite the manager to
witness, or participate in, some of your day to day version control
activities.

-- 
. .
 .  .
  .   .  <- Mysterious Powdery Substance
.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]