RE: How well does CVS handle other types of data?

[Paul Sander]

>--- Forwarded mail from Greg Woods

>[ On Thursday, July 12, 2001 at 18:23:51 (-0700), Paul Sander wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> I remind you of the definition of source files:  Files that cannot be derived
>> automatically from anything else.  The term "source file" does not not
>> imply ASCII text.

>May I remind you of the following:

>> >Note also that CVS uses RCS files.  RCS uses diff and diff3.  All these
>> >things together imply that CVS only handles text files.  Q.E.D.
>> 
>> RCS uses only diff to maintain the repository.  And modern versions of
>> diff, including the one recommended by RCS 5.7, include options to handle
>> binary files.  And RCS uses those options to maintain the repository.

Oops, that last sentence should have read:

        And CVS uses those options to maintain the repository.

Yes, friends, when using Gnu Diff, CVS uses the -a flag, which computes
differences even if files "do not appear to be text".  That's why CVS
can store binary files at all.

>Those points are irrelevant.  CVS does not use those options in any way
>suitable for the issues at hand.  The key point is that CVS tries
>valiantly to automatically merge files whenever asked to (whether when a
>current edit has been made, or when asked to merge branches) and the
>success of these merges depends entirely totally on the applicability of
>the diff3 algorithm to the content of the file(s) being merged.

Okay, replace diff3 when it's appropriate to do so.  We can start by
doing something else if -kb is set.

>If you try to use CVS to merge the binary representation of an image of
>a hammer and an image of a screwdriver you'll end up with merge
>conflicts that cannot be resolved without making an either/or choice
>between the three revisions that were to be merged (or without invoking
>a graphical editing tool and manually merging both images in some
>artistically pleasing way).

This is precisely why CVS should provide a means to register merge tools
appropriate to the data stored in its repository.

>The problem here is that if you've separated your configuration
>management tasks from your development tasks then when such conflicts
>are created by an attempt to merge such binary files you leave the
>configuration manager no choice but to hold the merge and throw the
>whole mess back at the developers so they can either choose between one
>of the three images or provide a fourth image for you to treat as the
>merged result.

Why is this a problem?  This is what we want.

But if the merge really must be automated, then the user can supply a
hint to decide which of the available versions of each unmergeable file
should be left as the result of the merge.

>This might be OK for a tiny fraction of non-mergable files amongst many
>normal text files (or when the developers are doing the SCM too), but at
>some point the headache caused by beating one's head against this wall
>time and time again gets just too much to bear.  The solution is simple
>-- just don't put non-mergable files in CVS in the first place (i.e.
>don't even start to bang your head on the wall)!

>> Using diff3 and the RCS-supplied merge tool is an option.  CVS uses it
>> because it's convenient, and there happens to be a performance advantage
>> to using it.

>Yes, but CVS USES DIFF3!!!!!  Whether it's an option in RCS or not is
>irrelevant!  CVS uses it NOW!!!!  It is not now an option in CVS!!!!!

And this is why CVS is inadequate for many of its users.  It should be
modified so that diff3 can be swapped out for something more appropriate.
Here, what is "more appropriate" is best left to the user, but there are
alternatives that should be palatable now.  Supplying hints to a 3-way
selection algorithm when -kb is set is one such alternative.

>>  However, pulling three versions from the repository and
>> invoking a different tool is equally viable.

>Well, maybe.

>However that's not the problem.  The problem is that the more merges you
>do, and/or the more CVS-non-mergable files you've got, then the more pain
>you encounter.

Merges are always a problem.  It does not matter if the data are ASCII
text or not.  But CVS compounds the problem by using a one-size-fits-all
merge tool that doesn't always work with what's fed to it.  The results
are almost guaranteed to be bogus, thus requiring the user to re-do the
merge the hard way.

>By simply avoiding ever putting CVS-non-mergable files into CVS in the
>first place then you avoid all pain (with CVS merges) right from the
>start.

Or, CVS can be modified in a small way to make life a lot easier.

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