"Greg A. Woods" wrote:
>
> [ On Tuesday, February 15, 2000 at 09:56:42 (-0600), David Thornley wrote: ]
> > Subject: Re: CVS File Locking
> >
> > I don't believe it is designed to do that. It's freely available
> > open-source software, and I've never met anybody in the community
> > that wanted to force somebody to do development in one specific
> > way before. You may want it to do that, but that's a different
> > statement.
>
> The fact that CVS was indeed designed to force concurrent development
> been discussed in detail on this list and is clearly evident both in the
> original CVS-I scripts and documentation, as well as in Brian Berliner's
> paper. You can believe what you will, but those are the facts.
>
Berliner's paper will be a good source; I have it very conveniently
to hand. I just skimmed through it again, and didn't find any such
statement. It seems to have been intended to show that concurrent
development works.
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.
> > 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.
> If you want to add more merging support to CVS (i.e. to diff3) for
> different types of files then that's an entirely different story than
> advocating locks. The former is entirely within the design goals of
> CVS but the latter is entirely without.
>
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).
> > 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. Some people
I think reasonable disagree, for reasons that I do not see the same
way they do. They allow CVS to be used in an environment with
both mergeable and non-mergeable files. Given the quote from the
abstract above, it looks to me like Berliner was talking about
a very general solution.
Further, "cvs edit" and "cvs watch" are a fairly straightforward
implementation of the first item in Berliner's "4. Future Enhancements
and Current Bugs", where he complains that it is not possible to know
who else is working on a file.
> (and before Paul Sander jumps up and down in a flurry again: CVS cannot
> be "CVS" if it supports hard locks. Period. This is not something that
> can be discussed logically. Either CVS forces the copy-edit-merge
> paradigm or it is not CVS.)
>
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.
--
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/
