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

[Greg A. 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.

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.

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).

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.

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!!!!!

>  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.

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.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>