RE: giving up CVS

[Paul Sander]

>--- Forwarded mail from Greg Woods:

>[ On Friday, September 14, 2001 at 14:25:41 (-0500), Thornley, David wrote: ]
>> Subject: RE: giving up CVS

>> Does RCS enable merging changes to non-text files?
>> 
>> Since it doesn't, what does it do better?

>I think you missed the point....  RCS is not that much more suitable for
>tracking changes to non-text files than CVS is.  It's equally tied to
>the text-based diff and diff3 algorithms.

It's only tied to those algorithms when displaying differences and
performing merges.  There are lots of situations, even in a CVS environment,
where those features simply are not useful.  And yet, the ability to perform
checkins and checkouts, apply labels, view revision history, etc., remain
very useful.  And CVS' other strengths, such as sharing a common repository
over a network, remain sufficiently compelling to apply it even if its
most touted features are ignored.

In other words, CVS is a fine tool for performing serial version control,
provided you don't need locks.  And that limitation is fine for a great
many shops.

>However RCS alone does not force a paradigm on its usage, and though it
>provides even more options for its usage than CVS does, this lack of
>"direction" makes it (slightly) more suitable for use with unmergable
>files than CVS is since a different paradigm can be enforced by the user
>on their use of bare RCS for this purpose.

>I still think the disadvantages of tracking binary files with bare RCS
>far outweigh the advantages.  People who work with primarily unmergable
>files generally don't manage changes and change sets in the same way
>people who work with source code do.  Often a simple serialised set of
>archives is more than sufficient for their needs.

>Indeed people who come to the software engineering field to learn about
>change management (because presumably we do it better than anyone else,
>though that's obviously an easily challenged proposition) should be more
>careful to ensure that they don't get misled into applying a solution
>that does not in any way meet their real requirements.  Software change
>management is very much unlike change management in other disciplines.
>One of the biggest differences is the degree of automation possible in
>software change management is not usually possible or even desirable in
>many other disciplines.  Even in the closely related disciplines of
>drafting and engineering changes are far less often made in parallel
>(either on branches or simultaneously on the same drawing/object).

I have supported environments where this simply is not true.  Applying
software change control methods is perfectly suitable for large projects
involving CAD tools with opaque file structures, provided expectations are
properly set and certain disciplines are adopted.  In our case, the project
was divided in such a way that no two people edited the same file on the
same branch concurrently.  Adding change control (as applicable to software)
was a HUGE win by tying sets of files to the defect tracking system and
(by enabling inclusion and exclusion of groups of related changes) we were
able to achieve a 100% success rate in the builds.  (The trade-off was,
of course, that not all changes were included; but they were the ones that
broke the build to begin with, or they depended on the broken changes.)

In this environment, the only disadvantages that CVS had were not related
to merging or concurrent development.  (They were in unwanted keyword
expansion, and the inablility to reorganize the sources in a meaningful way.)

>> There are a lot of things CVS does better than RCS.  CVS manages
>> concurrent development, branches, and works well by directory or
>> module rather than by file.  By using non-text files, the concurrent
>> part goes out the window, and branches become less useful.  The
>> rest of the advantages remain.

>I would suggest that the disadvantages far outweigh the advantages.

Suggest all you want.  Lots of people disagree.  Lots of people consider
the "concurrent" features to be of minor benefit.  I daresay that some
find the concurrent features to be annoyances, but then they're not
applying it correctly to their problem.

>The evidence can be clearly seen in this forum by examining the nearly
>decade's worth of postings by people whining about their poor choice of
>using CVS to manage changes to their binary files.

The reason there's a decade of complaints is because no one has tried to
give better support for binary files.  The complaints are the same
rudimentary ones repeated over and over.  And the complaints are not that
people have made a poor choice, it's that the tool offers excessively
poor support.

Nobody expects to perform concurrent development on files that can't be
merged.  If you ignore merging, CVS reamins useful for its checkin/checkout,
history, branching, labelling, and networking  capabilities.  That remains
true even for binary files.

>--- End of forwarded message from address@hidden