>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 15, 2000 at 14:33:51 (-0600), David Thornley wrote: ]
>> Subject: Re: CVS File Locking
>>
>> > > Besides, there are things that cannot be developed concurrently,
>> > > since they are unmergeable, for good reasons or bad.
>> >
>> > CVS is not designed to work with un-mergable files. Period.
>> >
>> I found no mention of such files in the Berliner paper, either
>> positive or negative. I will point out that CVS can at least
>> version binary files, which are not mergeable. It may not have
>> been designed to work with them, but it seems to not have been
>> designed not to work with them.
>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.
Keep in mind that the choice is to decide which change disappears
into the ether, and the answer may be a very impractical "neither".
It would be better to avoid the situation where such a choice is
required.
[...]
>> > > 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
>> > > in practice. Others have different opinions.) I assume it is your
>> > > position that CVS should not be used in such cases.
>> >
>> > 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 would like to hear about another method that avoids the choice I've
described above that doesn't rely on serialized development. I, personally,
don't know of one, but then you might know something I don't.
>> Perhaps you could show me where somebody else says that. The Berliner
>> paper seems to me to be about how concurrent development is possible,
>> with some mention in the second paragraph about how locking systems
>> like RCS and SCCS don't scale well. CVS seems to be about permitting
>> copy-edit-merge in a freely available tool. I don't see anywhere
>> where it is about forcing programmers to simultaneously working on
>> the same file.
>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.
>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).
The key here is "in their experience". Their source files fit a very
narrow standard, one that doesn't fit many real-world projects that were
initiated in the decade or so since that paper was written. I'm sure that
if Prisma required more than a few files that didn't fit that standard, CVS
would somehow support them. Maybe they did, and relegated their ownership
to a very small group of people who practiced serial development informally;
such efforts would likely have been omitted from the paper for any of a
number of reasons.
>--- End of forwarded message from [EMAIL PROTECTED]
