Re: Smoke, FUD (was Re: CVS corrupts binary files ...)

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Monday, June 28, 2004 at 19:02:19 (-0700), Paul Sander wrote: ]
>> Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
>>
>> I have never, ever advocated changing the format of an RCS file in a
>> way that would break the ci, co, rcs, or rlog programs.  And although
>> I strongly advocate the replacement of user-exposed diff and merge
>> tools, I have never, ever advocated the replacement of the diff tool
>> that computes the deltas stored in an RCS file.

>Indeed -- instead you would rather use different algorithms for storing
>deltas and for using them.

>That would be just plain stupid, if indeed not eventually dangerous to
>the integrity of a repository.

What are you talking about?  I can think of only two ways that CVS
"uses" the deltas:  Reconstructing complete versions, and annotating
version history.  For the purposes of this thread, which started out
with diffing and merging files, the tools require reconstructed versions.

Of course, the algorithms that produce the deltas and reconstruct the
original data must agree.  But that's all below the RCS API and is
completely invisible to the user.

Once the user has two or three complete files, he can apply any diff or
merge algorithm he wants to those files.  Recall the following sequence
of operations:

        co -pancestor file,v > a
        co -pcontributor file,v > c
        diff3 -E file a c

Once again, the algorithms and data formats that maintain the integrity
of the RCS files is hidden away and invisible to the user by way of the
co and ci programs.  The user can replace the invocation of diff3 with any
tool that he chooses to perform the content merge.  Once done, the user
uses ci to produce a new delta in the RCS files, using the very algorithm
that produces the correct data for subsequent invocations of co.

There's absolutely no danger to the integrity of the RCS file, unless
someone mucks with the innards of co or ci.  And nobody is even hinting
that making such changes is desirable, at least with respect to the
deltatext phrases in the RCS files.  (There have been several
recommendations to exploit the areas of the rcsfile format that explicitly
permit extensions, but extensions of this nature have absolutely no effect
on RCS' ability to store and reconstruct versions, which I have demonstrated
in a separate message.)

>The tools we now have for calculating and handling deltas are all
>designed to work _together_, not in isolation of each other, and that
>uniformity is as valuable to CVS as it is to RCS alone, if not more so.

What tools, specifically (and I mean, you need to name them and include
pointers to them so that the rest of us can look), are you talking about?
The RCS programs and CVS in its current implementation are the obvious
ones, and my comments withstand scrutiny on those.  What else are you
referring to?

>How about you go off and spend the next, say, two years or so
>intensively using such a scheme as you propose on a massively huge
>variety of projects.  That should give you about 10% of the experience
>the rest of the world has with using diff and diff3 and rcsmerge
>uniformly for both purposes.

>Then if you still think it's wise to use disparate techniques for
>storing deltas and for using deltas then you can show your results and
>raise your proposal here again.

>In the mean time please keep in mind that there are not just a plethora
>of tools for using diff-style deltas, but there's also an enormous
>amount of human experience with them too.

I look forward to seeing your list of references, so that we can debate
the relative value of interpreting ed-like scripts for a least-common
denominator level of functionality, versus parsing the entire content of
a reconstructed file and applying domain-specific algorithms that
understand the type of data stored there.

>You (and a few others) seem to want to throw the baby out with the bath
>water, and all just so that a few hair-brained and lame mis-uses of CVS
>will work "better".  In the mean time if you (and others) had learned to
>use the best tool for the job in the first place then you'd never have
>had to dream up such a half-baked idea.

CVS has a notoriously poor diff and merge capability.  Integrating the
user-exposed features with better tools is a very good example of using
the best tool for the job.  And it's not a half-baked idea; the whole
idea of plug-ins is well established in the industry, and its feasibility
in CVS is proven.

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