>--- Forwarded mail from [EMAIL PROTECTED] (Greg Woods)
>[ On Tuesday, February 15, 2000 at 13:55:28 (-0500), John Macdonald wrote: ]
>> Subject: Re: CVS File Locking
>>
>> I just re-read through the Berliner paper: "CVS II: Parallelizing
>> Software Development", Brian Berliner, Prisma Inc. I presume that
>> this is the paper that Greg was referring to in another post in which
>> he said "read the paper".
>Yup.
>> It talks about concurrent development. It describes the discovery
>> that concurrent development actually works, and that they hardly ever
>> had to do manual merges, and that those manual merges were almost
>> always simple to resolve.
>>
>> I didn't see anything that even seemed to say that it was a design
>> goal to forever onward prohibit any non-concurrent activities from
>> ever being possible in conjunction with parallel development. It
>> simply said that concurrent development had proved fully adequate,
>> having no significant drawbacks and some major advantage.
>The claim that concurrent development is sufficient is stated as a
>justification to why CVS only supports the copy-modify-merge paradigm,
>just as Sun's NSE tool which they refer to as the documented source of
>the idea. I have always interpreted that to mean that CVS forces
>concurrent development and to date I don't remember anyone giving any
>substantial rebuttal to that interpretation.
>One can easily conclude that since the author found concurrent
>development to be a correct and useful approach that indeed he found no
>reason to allow serialised development at the same time and thus within
>the confines of CVS there is no room for any form of support for
>serialised development.
You must remember what the authors source base was: The Unix operating
system, whose sources consist solely of "text files" (as defined by the
Unix operating system, which means they contain only ASCII characters,
with lines separated by the "line feed" character, and having a line length
not exceeding some arbitrary length in low thousands of characters).
The claim the author made is that the copy-modify-merge paradigm seems
to be a correct and useful one for that project, and indeed those software
developers have had good experiences with it.
He does not explore any cases where there are no viable merge methods for
his source files.
>> The cvs design is *not* carved in stone. Just because a proposal
>> does not match the original design goals of cvs does not justify
>> automatically rejecting it from consideration. Such a proposal must
>> be considered on its actual merits, rather than the Gospel of the
>> Design of CVS.
>Well no, of course it's not. However as I and others have tried to
>show, changing CVS' to support non-concurrent development will require a
>lot more thought and upheaval than just adding locks. After all why do
>you think the hack of using "cvs admin -l" is so unsuccessful!?!?!?
>It's certainly not because it's hard to use.
To plagiarize a quote from Einstein, a tool must be as simple as possible,
but no simpler. "cvs admin -l" is too simple. It simply seeds an error
condition and the user relies on it to try to prevent conflicts with
unmergeable sources relies on error recovery that is euphemistically
ungraceful, and the warning comes out only at commit time (and not when
the user decides to make a conficting change, when it's needed if the
conflict is to be avoided). In short, it's not well thought out and poorly
integrated with the rest of the application. On the other hand, the
"cvs admin" command in total performs very well its intended purpose: To
bring all of the "raw" power of RCS to the CVS command line.
>In the end we have also shown that it is not necessary for CVS to have
>hard locks in order to deal with a few unmergable files. Whether you
>agree or not relates directly to how well you buy into the claim that
>the copy-modify-merge paradigme is correct and useful for software
>developers.
Theoretically, it's unnecessary to have locks in any version control
system; everyone can rely on hallspeak exclusively to control access to
source files. Theoretically, we don't require directory level locks
in the CVS repository to coordinate updates and commits because we can
verbally coordinate them so that they don't trounce each other. But as
everyone here knows, such a system just doesn't work in practice. That's
why locks were invented, to formalize and enforce such agreements.
I buy into the copy-modify-merge paradigm when it's appropriate. But
it's only appropriate when all three stages are available, reliable,
and predictable. With many types of source code, the last step just
isn't viable. And when one step is missing, the whole method breaks.
And I discourage attempts to apply the method when it breaks, because
breakage (in the CVS implementation) results in corrupt data that may
be difficult to recover.
So, when merging isn't possible, something else is needed. Hence,
people demand a secondary method that applies generally. Locking is one
method that is well understood and relatively easy to implement. I
have no particular love for locking, and would entertain another method
that neither relies on ad-hoc communication outside of the version control
system to work (i.e. performs such communication itself, or somehow
enforces communication through other channels) nor requires content merges
to be performed when the nature of the source code in a file precludes it.
Greg's sermon of using the right tool for the right job is well taken.
But under conditions where concurrency is preferred but not possible on
every file in a project, and the project is on a budget that limits
its ability to buy more capable tools, CVS (with all of its limitations)
might still be the best tool available even if it does not meet all of the
requirements of the project.
So, here are some alternatives: Kludge up a hybrid system consisting of,
say, CVS and raw RCS; abandon CVS in favor of a more unpleasant tool that
at least is capable of operating correctly on all of the project's source
files; generalize CVS.
I have no first-hand experience with any shop that was willing to use
two source control systems on a single project. I have heard of one
shop that has used two distinct tools for source control on the same
project, but the tools were substantially similar (SCCS and RCS) and
the project (the Unix operating system) was divided among many development
groups who used the same tool internally. Informal discussions with
various people indicate a general distaste of mixing source control
tools in a single development environment. So, the hybrid system
seems to be both impractical and unpopular.
Abandoning CVS doesn't help promote the concurrency model, unless the
new tool supports it. If there is another free one, I'd like to hear
about it and check it out. But in reality if a shop is on a budget then
chances are they'll cobble up some SCCS or RCS wrappers, or license one
of the cheaper commercial tools that use locking. If they can afford a
more expensive tool, the shop might license something like ClearCase,
which supports both the concurrent and serialized methods.
The final alternative is to generalize CVS. This seems like the
best solution for those of us who prefer the concurrent model when
it's available, require serialized development for part of a project
where merging is meaningless, and have a tight budget. Indeed, it seems
like a no-brainer because the consequences of deploying one of the other
alternatives are so much more unpleasant.
>--- End of forwarded message from [EMAIL PROTECTED]
