Re: Correct options for export

[Greg A. Woods]

[ On Thursday, July 12, 2001 at 18:11:46 (-0400), Eric Siegerman wrote: ]
> Subject: Re: Correct options for export
>
> On Thu, Jul 12, 2001 at 05:09:03PM -0400, Greg A. Woods wrote:
> > The problem is that you can't turn off the features in CVS that are hard
> > (impossible) to use once you've added binary files to a repository.
> 
> What specifically are those features?

Merging of branches and merging triggered by concurrent editing.

You can easily avoid them if you know to do so, but you can't turn them
off without changing the code.

> The two worms I can think of are:
>   - The -kb mechanism is fragile, and when it breaks, the file
>     gets corrupted.  Well, that's what this thread is about
>     fixing.

The -kb option isn't just fragile -- it's a wart.  It's what induces you
into giving yourself a future headache.  The best fix is to remove the
wart completely.

Unfortunately that makes the one place where the wart isn't really all
that noticable impossible to handle (binary files on vendor branches).

The best compromise is therefore to improve the documentation and to
continue chanting the mantra "CVS doesn't do non-text files!" until it
becomes a thing of lore and legend such that nobody can encounter CVS
with incorrect perceptions of how to best use it.

In the mean time those who are certain they understand the issues can
continue to store their precious non-text files in CVS, but hopefully
without creating a false legend about how well they think this works.

Fundamentally even the proposal to create a non-compatible variant of
CVS that has hooks to invoke other kinds of merge tools won't solve
problem that some kinds of things are never going to be mergable and
that there's always going to be a need to be aware of what they are so
they can be avoided.  Even if you have CVS invoke The GIMP with a script
do merge two variants of an image together (based on some
algorithmically derived delta of each from some prior image variant),
you still have no way to check for conflicts other than to either read
the commit logs for each variant and/or ask the artist(s) who created
each whether or not the resulting image is "right" (does it maintain the
intent of each change?  are there any visual conflicts that need to be
cleaned up?  etc...).  In other words you still can't always make it
easy to merge branches together.  The secret to CVS' success at merging
text files is that conflicts in text-file merges are always plainly
obvious and lack of conflicts usually means that the change applied
cleanly.  Obviously this only works with text based documentation and
source code because of the way we generally visually lay out our
documentation and source in a text file.  You'll note that merging works
far less successfully with plain-text documentation if you do even
something so simple as re-fill a paragraph in which you've made a
content change.  The only saving grace is that if you re-fill the whole
paragraph every time then it'll be a major part of the paragraph that's
in conflict and that'll force whomever resolves the conflict to
carefully proofread to discern the actual change in each variant and to
correctly create a merged variant that has the desired final meaning.

It's the same as Noel's example of re-formatting all the white-space in
your code -- you just can't do that unless you draw a line in the sand
and say "no more merging".  Merge tools that fully understand both the
syntax and the grammar (if not even the semantics) would be the only way
to get past such a barrier.  Tools like the Smalltalk system browser do
this in a very coarse manner by recording whole methods in change sets.
In combination with programming conventions that try to convince
programmers to only fix methods and not to change their interfaces (but
instead introduce new methods with new interfaces), this form of
changeset handling has worked very well for over two decades.  That's a
very language-specific solution and its use in a CVS-like tool would
require replacing both the diff and diff3 algorithms so that deltas in
the repository become what Smalltalker's call "change sets".  I.e.
there'd be far more incompatabilities in the repository than have been
alluded to so far!

> Are there other problems besides these two?

Any form of merging, either of branches or of concurrent edits cause
problems with binary files.

The problems start out small, but escalate until you've got a headache.

The worst scenario is when you inherit someone else's headache.

If CVS were kind and gentle it might not allow you to create a scenario
which might cause future headaches, either for yourself or for your
successor.  If CVS users were to be kind to potential CVS users they
would tell them never to add non-text files to CVS (unless they're only
on a vendor branch, and then only if they promise never to try to make
local changes to such files).

-- 
                                                        Greg A. Woods

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