info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Sander
Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
Date: Thu, 1 Jul 2004 15:17:03 -0700

>--- Forwarded mail from address@hidden

>[ On Monday, June 28, 2004 at 14:58:03 (-0700), Mark D. Baushke wrote: ]
>> Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) 
>>
>> Yes, but diff is not diff3. diff is used for the
>> delta format. diff3 is used by rcsmerge, not for
>> fundamental version deltas.

>I think you're confused -- the differencing algorithms used are
>fudamentally intertwined (and fundamentally based on units of lines of
>text).

This true, insofar as to maintain the integrity of the RCS files and
to reconstruct complete versions.

>Pretending you can do merges using some other algorithm while still
>trying to store your deltas in unix diff format is just leading everyone
>down the garden path to a dark dank corner no-one really wants to be in.

What do we care what format the versions are stored in, as long as we
can recover the complete files and apply any tool we want to them?

Although I can imagine such a thing, I don't know of any merge tool
reads the ed-like scripts produced by the diff program and presents
a user interface to apply or omit specific deltas to an input file.
It's an interesting idea, and it might even be useful, but its
utility is limited.

On the other hand, reconstructing entire versions and applying
content-specific tools is far more useful.  For example, there is
research on hierarchical differencing algorithms that compare
tree-like structures like the ones produced by parsers of programming
languages.  I foresee that this will lead to a new wave of merge
tools that provide a much higher level of utility than line-based
tools like diff3.  This kind of work just isn't possible with line-based
deltas produced by the diff program.  (It's also possible that they
could lead to a new wave of archivers that provide RCS-like capability
but use the hierarchical diffs in the deltatext records, which will be
interesting.  But nobody's suggesting a possible replacement of the RCS
layer just yet.)

>The uniform use of differencing algorithms and their corresponding merge
>algorithms (which are of course just "editing" scripts), is what makes
>it worthwhile to use something like RCS as the foundation for CVS in the
>first place.

It's what makes it possible for systems like RCS to exploit the similarity
of sequential versions for efficient storage, to be sure.  But applying
a delta to reconstruct a version is very different from doing a content
merge of two or three fully reconstructed files.

>I.e. it is not sufficient to just use the RCS delta format as a means of
>archive compression -- that format is integral to the whole idea of
>detecting, reporting, and merging, changes in any RCS-compatible tool.

Once again, no one is suggesting changing the way that RCS works.

>> Are there really utilities out there that try to
>> to read RCS formats directly and do not allow for
>> rcsfile(5) syntax to be used? If so, could you
>> name any of them?

>Humans, for one.  :-)

>(I know some folks can do manual merges of SCCS files, and though the
>same techniques won't work quite so well on RCS files because of the
>reverse delta thing, there are still a great many other valid reasons to
>read and even repair RCS files by hand.)

>There are a number of commercial software pacakges which are "GNU RCS
>compatible", apparently without using RCS source code, with the most
>"popular" perhaps being CS-RCS (though I've not confirmed 100% that it
>does not use RCS source code).  SourceCodeManager is apparently another,
>and P4D yet another.

>Perforce also uses RCS compatible files as its archive format, but I'm
>not sure if its core RCS handling was derived from RCS source code or not.

>I think I've just scratched the surface too, if any of the rumours I've
>heard are close to true.

Well, if these tools are truly "RCS compatible" then they should be able
to ignore the newphrases we've been talking about.  And since there is
no proposition to change the format of the deltatext phrases, or any of
the other standard components of an RCS file, those tools should continue
to work.

BTW, I have also written a couple of tools that parse the RCS file syntax.
They conform to the rcsfile format and should tolerate extensions made as
newphrases as specified.

I have also seen commercial tools derived from RCS (specifically, the MKS
variety) that have made proprietary extensions and are no longer compatible
with the Gnu standard.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]