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