[Top][All Lists]

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

Re: locked files

From: David H. Thornley
Subject: Re: locked files
Date: Mon, 30 Oct 2000 12:51:13 -0600

Thomas Olausson wrote:
> > This topic has been discussed numerous times and I still haven't seen an
> > absolute need to use "cvs admin -l".
> Well, some people don't trust that if someone gets a conflict when
> trying to merge, that the resulting file will be OK, because of human
> errors.
I don't trust people to do the right thing when merging manually.

Given a shop of reasonable size and activity, somebody's going to be
working on program X when it needs to be fixed Right Now.  How are
you going to handle that?

CVS model:  Make the quick fix, person doing the long-run development
merges in the change, accounts for it, life goes on.

Locking model:  There are several possibilities.  I've seen them.
1.  Somebody makes the quick fix, by getting the program lock.
Person doing the larger development keeps interim copy of program,
and checks it back in without the quick fix.
2.  Somebody makes the quick fix, and the person doing the larger
development hand-merges it in incorrectly, creating a new bug.
3.  Somebody makes the quick fix, and the person doing the larger
development recreates the changes on top of the newly fixed version,
4.  Quick fix is made and hand-merged in without program assistance.

In a case like this, locking is useless.

What you need in a case like this is communication.  I've worked in
a shop where we wrote "Please see me" on the listings in the listings
books if we were going to make a change.  That worked.  We had less
problems with conflicting changes than we did in the place where we
used SCCS and locked.

> Locking stalls development, but encourages that one person does some right
> without disturbance from others.
As long as you can guarantee a lack of disturbance, this works.  I
don't see that this is a realistic guarantee.

When (not if) you have two conflicting changes to a file, often because
it's being modified (and is not yet ready to use) and it needs a quick
change, you need either communication or a reliable merge process.
CVS' merge process isn't entirely reliable, but it's very good, and
as long as people keep an eye on what's going on in programs they're
working on it's a very good solution.  CVS can also provide a means
of communication, with its edit and watch facilities.

reply via email to

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