Re: CVS corrupts binary files ...

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ]
>> Subject: Re: CVS corrupts binary files ...
>>
>> Yeah, well, sending such hapless people away is easier
>> than fixing the tool.

>The tool is not "broken" -- I.e. there's nothing to fix!

>CVS is designed _only_ for tracking changes in human written text files.

So you say.  I maintain that the diff and merge tools can be easily
swapped out without making significant changes to the CVS design.
With regard to merge tools, I proved my point with a patch posted to
this forum on Sept. 16, 2001.  I've included that patch at the bottom
of this message.

>If you want to design (and implement) a new tool that does work well
>with non-text files then please do so.  That'll give us yet another tool
>to recommend people use when they want to.

No need.  See the patch below.

>>  Demonstrating that such support
>> could be added to CVS was done in less than eight man-hours;

>Nope -- it's just not possible, as you should well know.  This is a
>fundamental and purposeful design limitation in CVS.  The entire concept
>of concurrent editing, which is central to the design and goals of CVS,
>is completely antithetical to managing binary files.

I don't believe it was a "purposeful design limitation".  CVS was initially
designed before binary source formats were common, and it just didn't
happen to include a plug-in method to support them.

Keep in mind also that there's a difference between "binary files" and
"mergeable files".  The two concepts are in fact orthogonal; there are
mergeable binary types (given a suitable tool), and there are unmergeable
text types.  CVS is bad at storing unmergeable files, no matter whether
or not they're binary files.  CVS can be easily modified to support
mergeable binary types, as I've demonstrated, without significant impact
to its design.

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