"Greg A. Woods" wrote:
>
> [ On Tuesday, February 15, 2000 at 14:33:51 (-0600), David Thornley wrote: ]
> > Subject: Re: CVS File Locking
> >
> > So, please tell me where in Berliner's paper it says what you claim
> > it says. You can use either the page numbers or the internal
> > subdivisions. Alternatively, you could retract your claim.
>
> Please refer to my previous reply to JMM under this thread.
>
Yes, and it looks thin. IIRC, it was the second paragraph of the
paper proper, the part that mentions the problems with locking,
serialized, development. There are problems with serialized
development. I think we can all agree on that, particularly if
we've used it in the past. I take this as meaning that another,
more parallel, method would be desirable, if it works, and the
rest of the paper is devoted to showing that CVS works. I think
we can all agree that concurrent development is good, when it
works (or we wouldn't be here).
> Well, OK, that's not exactly what I meant to imply. Indeed CVS works OK
> with non-mergable files. The issue is only with how one resolves
> conflicts. If it is always OK to make a binary choice between two
> changes then yes, CVS works just fine with non-mergable files.
>
Which is sufficiently close to false to not be worth dealing with.
There are files which cannot be merged. Feel free to curse the
people who made some of them so recalcitrant, if you like. However,
I know of no shop where developer work is considered so freely
disposable as to say "OK, Jack and Jill have conflicting changes to
the VB program. <flips coin> We're keeping Jill's changes. Sorry,
Jack, good work, but we'll just have to tell the customer we're not
going to fulfil that requirement."
> > > > These have
> > > > to have some form of lock. (From experience, I think "cvs watch on/
> > > > cvs edit" is adequate locking, and hard locks would be no better
> > >
> > > No, they do not. For those very few files for which a merging algorithm
> > > cannot be developed "cvs edit" and friends are far *MORE* than
> > > sufficient for *ALL* purposes CVS should ever be put to use for. Even
> > > they are over-kill in my opinion.
> > >
> > "cvs edit" and friends are, in my opinion, sufficient.
>
> Sorry, but I got carried away over-reacting to the opening sentence in
> your paragraph. As you can see from my reply I mostly agree with you
> (but strongly disagree with those who think serialised development is
> the only answer to the problem).
>
I'm going to take issue with the final "the" in your paragraph. I don't
see that there is one single problem. It may well be that all the
controlled files at your shop can be merged. Right now, it's true of
mine. I don't know how many people here know about "cvs edit" and
"cvs watch". I haven't told anybody.
However, I'm not willing to say that that will be true forever. Things
change, and it's possible that we'll need to put nonmergeable files
into the repository in the near future. We need to have a mechanism
to manage those in CVS, or we'll have to move off CVS, which would
be a great shame. We agree that the concurrent model is better,
when it works.
> CVS was designed only with the copy-edit-merge paradigm in mind.
> Clearly it doesn't force programmers to always make simultaneous changes
> to the same files and I certainly didn't mean to imply that it does.
> Indeed good project management outside of CVS is often focused on how to
> reduce conflicts and the need for merges and there's nothing wrong with
> this.
>
Your first sentence is at least close to true, although it doesn't
seem to account for the first "to-do" item at the end of the paper.
Nor am I trying to say that CVS should substitute for management,
since no revision control system can.
I'm saying that, to me, the paper reads like "Look at this neat new
development system we've devised!", and seems to be devoted to showing
that concurrent development works. After all, we still have trouble
convincing people that it works, and this is some years later. It
looks to me like it is advancing a new method to deal with known
problems with the old, and I don't see anything doctrinaire in it.
> All I'm saying is that CVS forces developers to work within the
> copy-edit-merge paradigm -- there is no option to use hard locks and
> Berliner justified this by showing that there has been not real need for
> locks in their experience (and we can now amplify his conclusion though
> the ongoing half-dozen years of experience a wide variety of people have
> had with CVS).
>
Berliner justified this by showing experience in a rather limited
domain. It's a very important domain, but hardly universal. It
works well on mergeable files where changes within the file are
localized. (It doesn't work perfectly. What does?)
The issue is that there are files for which copy-edit-merge doesn't
work, generally because "merge" doesn't work. Some of these can
probably be dealt with by adding additional merges, but it seems
to me that there's always going to be a good deal of catchup going
on, so a shop that works on a variety of systems is likely to
always have files that can't be merged.
The question is whether it is worthwhile to allow CVS to be used in
these shops, which (I think) are going to become increasingly
important. If CVS is copy-edit-merge only, shops with mixed files
will find it impractical for some of their files, and will adopt
a system that works for all of their files. It is likely to not
support concurrency nearly as well as CVS.
CVS is a good piece of software. I would hate to see it become
marginalized, and in order to avoid that it does need to support
serialized development, preferably on a file-by-file basis.
--
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/
