[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
Tue, 29 Jun 2004 02:18:26 -0700
>--- Forwarded mail from address@hidden
>[ On Monday, June 28, 2004 at 01:44:36 (-0700), Mark D. Baushke wrote: ]
>> Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
>> The RCS format is very extensible and in fact the
>> CVSNT folks have extended it already and I have had
>> no problems using CVSNT repositories in conjunction
>> with either CVS or RCS.
>"very" is an over-statement of the first order! ;-)
>Sure, it's an extensible format, but not in the way that's been
>suggested. You can't get rid of the _exclusive_ use of diff et al
>without entirely losing compatabilty with RCS.
Nobody has suggested abandoning diff for computing RCS deltas.
All discussion relating to replacement of diff and merge tools
have revolved around the user interface. That's completely
>> I do not see support for your assertion that
>> compatibility is "far more" than just the
>> adherence to the syntax defined in rcsfile(5).
>Sadly rcsfile(5) only describes the meta-syntax, not the nuts&bolts of
>how RCS files work and how they're actually used by the RCS package.
>> So, I believe that adding a
>> 'diff3hint someprogram;'
>> line to the RCS file should not be a problem for
>> "co" to still be able to checkout each and every
>> version of the file.
>"diff3hint" in the way you're hinting it might be used is insufficient.
>RCS directly interprets the content of the delta text information,
>e.g. the likes of:
> @d5 1
> a5 1
> some new line of text
> d256 1
>See, for example, lib/rcsedit.c from the RCS source distribution.
You are obviously missing something here. We're talking about
adding a newphrase in the admin, delta, or deltatext productions.
Using the deltatext production and your diff output as an example:
@this is a log message
some new line of text
This obviously extends the RCS file format in a way that does
not break compatibility with the existing RCS software. Following
is a complete RCS file that contains not one but three extensions,
but they're done in a way that is supported by the RCS file format.
And none of the RCS programmatic interfaces break.
comment @# @;
admin-ext @this is an admin extension.@;
date 2004.06.29.09.08.54; author paul; state Exp;
date 2004.06.29.09.05.20; author paul; state Exp;
delta-ext @this is a delta extension.@;
date 2004.06.29.09.04.53; author paul; state Exp;
date 2004.06.29.09.04.24; author paul; state Exp;
@Added the beep!
@This is a test. This is only a test.
If this had been an actual emergency,
it would have been too late.
deltatext-ext @this is a deltatext extension.@;
@First change. Needs more work.
>Any modification of the diff algorithm would almost certainly require
>changes to the syntax of this delta text.
Actually, this isn't true. The diff program itself implements multiple
algorithms. But that's neither here nor there because nobody is
recommending that the format of the differences be changed.
>As far as I can tell the extensibility of the RCS,v syntax does not go
>so far as to provide for callouts to add-on programs and I'm arguing
>that it's _far_ too late to try to modify this widely used standard file
It's never too late to update a standard. In any case, RCS file
extensibility has been in the standard for a very long time now.
>So, how _exactly_ do you propose to convince the standard "co" program
>(or the equivalent in any other RCS-compatible tool suite, including the
>current CVS implementations) to actually make use of the new delta
>text syntax that such a hack would create?
>I.e. How do you propose to make it possible for the standard RCS tools
>alone to re-create _every_ revision from all files created by this
Simple: The delta text would not change. See above.
>It's simply not possible. Like I said, only the bare surface of RCS
>compatability is scratched by the meta-syntax described in rcsfile(5).
Absolutely untrue, as demonstrated by the RCS file above.
>The RCS file format is intricately intertwined with the unix diff
>algorithm, which is itself tightly dependent on the "normal" use of
>lines of text to represent elements of a the source files being managed
This much is true.
>(at least when it comes to automated merging for concurrent editing).
But that is not.
The diff and merge algorithms that the user applies are distinct from
the diff algorithm that computes the deltas. They can be changed, as
I've demonstrated before on several occasions. It so happens that
the rcsdiff and rcsmerge programs, and CVS itself, use the same
programs forr both purposes, but there is no technical reason for
them to do so.
>Meanwhile there are other change delta file formats and other version
>tracking tools that use those other formats, and often there are also
>tools that will convert RCS/CVS repositories into those other formats.
>I.e. there's no _real_ fundamental need to hack on RCS,v syntax.
This is true, if you're willing to live with the status quo. If you
want to make your life better, then extending the RCS file format
(in supported ways) is an enabler.
>--- End of forwarded message from address@hidden
Re: Smoke, FUD (was Re: CVS corrupts binary files ...), Paul Sander, 2004/06/28
- Smoke, FUD (was Re: CVS corrupts binary files ...), Paul Sander, 2004/06/17
- Re: Smoke, FUD (was Re: CVS corrupts binary files ...), Paul Sander, 2004/06/29
- Re: Smoke, FUD (was Re: CVS corrupts binary files ...), Mark D. Baushke, 2004/06/29
- Re: Smoke, FUD (was Re: CVS corrupts binary files ...), Paul Sander, 2004/06/30