[Top][All Lists]

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

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

From: Greg A. Woods
Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
Date: Mon, 28 Jun 2004 16:32:08 -0400 (EDT)

[ 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.

> 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.

Any modification of the diff algorithm would almost certainly require
changes to the syntax of this delta text.

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
format 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
hacked system?

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).

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
(at least when it comes to automated merging for concurrent editing).

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.

                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>

reply via email to

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