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

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Greg,

Greg A. Woods <address@hidden> writes:

> RCS compatability is far more than just the
> adherence to the syntax defined in rcsfile(5).

Is it? I think I must be missing something here.

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.

> If the generic "co" program from the RCS package
> cannot extract any and every revision of a file
> from a file claiming to be an RCS file then that
> file is clearly not RCS compatible.

Sure, I agree with your statement. If a generic
"co" program is not able to extract any and every
revision of a file from its file,v form, then it
is not RCS compatible.

I do not see support for your assertion that
compatibility is "far more" than just the
adherence to the syntax defined in rcsfile(5).

In particular, I am not aware of any fundamental
problems rcs 5.7 will have if someone were to
introduce a new keyword which would name a program
other than diff3 to be used in rcsmerge
operations. At most, I would expect a warning
message via the warnignore() function which would
specify

co: file,v: warning: Unknown phrases like `diff3hint ...;' are present.

and even so, a 'co -q file,v' would not generate
such a message.

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.

Given that this would appear to be the desire of
at least a few folks out there who might want to
make CVS do a better job at merging structured
ASCII files such as XML or HTML format. And
further, that you seem to have objections to this
approach. And while I have known you to bring up
points I have overlooked in the past...

This time around I just do not see anything that
would preclude such an approach of using an
external diff3 hint 'replacement' program for
doing a 'cvs update -jtag1 -jtag2' operation.

I will stipulate that such a program will likely
need to live on the server and furthermore that it
would not be interactive. In the absense of
finding such a program, CVS would likely resort to
using diff3 as a fallback, so its arguments would
likely need to match those of the diff3 program
itself... at least to the extent that cvs currently
uses various arguments to diff3.

So, as I trust that you have an example in mind
that is a conflicting case, I must clearly be
missing something here. I would take it is a favor
if you could ellaborate in concrete terms why
adding a new keyword and value to existing RCS
format files to support an alternative to diff3 is
not a viable path for a hook that users may wish
to exercise.

If there is some other communication error that
has entered into the thread, I must have missed
it. Feel free to point it out, but I would still
be interested in your view of the following
thought experiment.

Let me state the scope of the thought experiment:

Goal: Provide a means whereby a cvs administrator
may cause a program other than diff3 to be used
when doing merge operations as a part of a
three-way merge of files in a sandbox. This
program might be defined as a keyword used as the
value of a 'diff3hint' followed by an 'id' which
could be looked up in a table that cvs could keep
to determine which executable and any additional
arguments above the diff3 form arguments might be
required.

Assertion: The diff3 replacement must handle
all of the args that cvs normally passes to diff3.

Assertion: The diff3 replacement must not be
interactive in nature for client/server repository
uses.

Assertion: The diff3 replacement must be able to
run just given the three versions of the file
without any other state.

Assertion: That cvs continue to write new RCS files
in adherence to the syntax defined in rcsfile(5), but
allowing the introduction of one or more new phrases
and associated id word values as allowed for by the
RCS format syntax.

It would be left to the extension designer to
determine the method whereby such a new RCS phrase
would be written into the CVS repository versions of
the files.

        Thanks,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFA39pz3x41pRYZE/gRAhjEAJ94c9uKJEwZww8lGAFGQJW68vvEswCfX3Ae
HoyCY1oAu/1+v9jOMxBXflE=
=u1L8
-----END PGP SIGNATURE-----