Re: giving up CVS

[Paul Sander]

>--- Forwarded mail from Greg Woods:

>[ On Friday, September 14, 2001 at 17:36:50 (-0400), Antonio Bemfica wrote: ]
>> Subject: Re: giving up CVS
>>
>> The fact that a user versioning binary files will not be able to take full
>> advantage of CVS's power to parallelise software development does not mean
>> that CVS is of no value to him. CVS IS a versioning system and will track
>> changes to non-text files. If this is what the user wants, CVS is a
>> suitable tool for the job. 

>Why then have there been so many complaints about how unsuitable CVS is
>at managing binary files, especially mixtures of binary and text files?  :-)

It's because repeated calls for change have gone ignored.  Ignoring
complaints does not make them go away.

>CVS was designed to impose a paradigm of parallel software development
>(in order to solve problems specifically brought on the designer's
>colleagues by tools which explicitly serialized development activities).

>CVS is built on top of tools which exclusively use text-based algorithms
>to manage content and to detect and merge changes.

CVS *was* built on top of tools which exclusively *used* text-based
algorithms to manage content and to detect and merge changes.  Since RCS
5.7 came out circa 1993 and the subsequent CVS support of the -kb
keyword expansion capability was added, CVS has been able to "manage
content" that was not ASCII.

Today CVS still uses ASCII-only merge tools, but I've shown recently how
simply that can change, and I provided sample code to demonstrate it.  Now
that we know that it is possible, it's just a question of how much people
really want the capability.  There's room for debate on the best way
to build in the capability, because hacking paths clearly isn't it.

>If people can hobble about using CVS with such restrictions on binary
>content then that's fine -- for them -- however it seems important to
>continually remind people publicly that CVS is not appropriate for
>tracking changes to non-text files (or anything else but exclusively
>text files, for that matter).

CVS is not appropriate for tracking non-text files insofar as the people
who have commit permission to the definitive sources continue to ignore
these calls for change.  CVS is perfectly capable of supporting even
unmergable file types with only minor changes to its logic, specifically
by adding an extensible mechanism to select the correct merge tool for the
data type at hand.

>Note that despite all of the promises of parallel software development
>it is still often necessary to force expert software develoeprs to use a
>tool like CVS because of apparently unfounded fears of the potential,
>but in reality very rare, problems it might introduce.  Let this be a
>warning to all who think they can easily and successfully use CVS for
>managing non-text files.  If software developers otherwise very familiar
>with version control and change management are wary of the risks of
>using a tool that forces them to accept parallel development activities
>for text files, don't be lulled by unqualified statements of success
>into believing there's no risk to using CVS to manage non-text files.
>Clearly the risk to your success with binary files is far higher than it
>is for source code represented as ordinary lines of text.

This is only true as long as CVS treats everything as text files.  There
is nothing holding us back from modifying CVS to accomodate non-text
files in a meaningful way and still retain the concurrent development
paradigm intact.

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