[ 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.
> > > 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.
> Additional sorts of merges would be good. It's require additional
> code, of course, but it'd be worth it. Handling non-mergeable
> files does not seem to me to be entirely foreign to "a freely
> available tool to manage software revision and release control
> in a multi-developer, multi-directory, multi-group environment"
> (from the abstract of Berliner's paper).
There are some tricky issues to deal with, and indeed these issues have
been hashed over several, no, many times in the past in this forum.
Naturally people needn't rely on the merge tools that are integrated
into CVS. There is reasonable support in PCL-CVS, for example that
allows one to use Emacs tools to do such merges and clearly if any tool
could merge VisualBASIC files then it could be used just as well. There
are some minor fixes that could be made to CVS to make it easier to
employ such tools but these are only minor annoyances.
> > > 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).
> 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).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
