Tobias Weingartner wrote:
>
> On Tuesday, February 15, David Thornley wrote:
> >
> > Besides, there are things that cannot be developed concurrently,
> > since they are unmergeable, for good reasons or bad. These have
> > to have some form of lock.
>
> No, they do not *require* some form of lock. Using some form of
> lock is one way of dealing with these files. Simple selection to
> resolve the conflict is another.
>
I have been imprecise.
There are files that are non-mergeable for various reasons, that still
are changed frequently in the course of development. If two people
have changes to make on a file that is not mergeable, then it is
probably not acceptable development practice to have them both
make changes and have a decision procedure to see whose changes
get blown away.
Under these circumstances, it is usually a good idea to have one
person actually modifying the file, and all others perhaps making
notes on the changes they will make. If they go further and
modify the file, somebody's work is going right into the bit bucket.
The person modifying the file may be referred to as having some sort
of lock on it. It doesn't have to be a hard lock. In my experience,
writing a "see me" on the listing in the master listing repository
works (although very few shops have master listing libraries and
racks of punch card decks any more), even in a shop with loose
procedures. IMNSHO, this can be achieved with CVS as it currently
exists, with "cvs watch on" and "cvs edit". You can speak of
an editor as having a lock on a file. It isn't an exclusive lock,
and people may want to create such. It doesn't actually prevent
commits, and people may want to change that. However, I think
this can be considered as "locking".
It seems likely, to me, that more and more shops will have a mix of
mergeable and non-mergeable files, and that they will become more
and more intermixed. This will obviously change. Some types of
files will acquire merging algorithms, and some morons will create
new file types that gratuitously resist merging, and other people
will create file types where it's genuinely difficult to merge them
in a meaningful way.
If CVS is to continue to be useful, it needs to handle both mergeable
and non-mergeable files well. (It wouldn't hurt to allow the use
of different merging algorithms by file type, defined somehow,
either.)
But what it comes down to is that there are cases where concurrent
development just doesn't work, and changes simply have to be made
serially. Making serial changes in any efficient manner implies, to
me, that a maximum of one person or team is changing a file at one
time, and that other people and teams will have to wait to make
their changes, or find that they have to redo them later. In that
case, the person or team making the change can be said to have the
lock, in whatever form the lock is. That is why I say these sorts
of files require some form of lock.
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
