>--- Forwarded mail from [EMAIL PROTECTED] >[ 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs