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

[Paul Sander]

>--- Forwarded mail from address@hidden

Mark, I agree with your response to Greg's claims about RCS
compatibility, or the lack thereof.

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

Rather than use a hint to expose an implementation detail, I suggest
recording a data type instead.  Maybe even a MIME type.  Then provide
a suitable mechanism to map data types to tools that are appropriate
to the environment.

BTW, CVS no longer uses rcsmerge; it co's the necessary versions
and runs diff3 directly.  So in a CVS context, pushing this capability
down to RCS isn't really a requirement.  However, I recognize the
usefulness of doing so, and would not oppose such a feature.  On the
other hand, doing so will likely be a duplication of effort because
CVS has client/server concerns that RCS does not, and that may necessitate
a different implementation.

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

Not just structured ASCII files as you describe, but any file
containing structured data for which a merge tool is available.

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

I don't believe that such a program MUST live on the server.
Merge tools, like editors, have a way of becoming religious
icons, in situations where users have a choice.  Under such
circumstances, it becomes important to have client side
mappings between data types and merge tools.

Additionally, I don't believe that merge tools necessarily
need to be fully automated.  After the relevant versions have
been downloaded to the client (and the repository locks have
been cleared), the merge tools can run interactively.
However, I believe that CVS current intersperses merges with
downloads, and that would need to change before interactive
merges can be supported.

Also, CVS currently relies on diff3-style mark-ups to warn the
user when merge conflicts remain present at commit time.  Though
strictly speaking such warnings are not necessary, they are
incredibly useful.  And they'll be lost unless merge conflicts
are recorded another way.  One way is to lists conflicts in a
file stored in the CVS directory.  At commit time, skip the
scan for diff3 mark-ups and instead read the conflict list and
compare mod times of the relevant files.  If they have changed,
assume the conflicts have been resolved.

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

Again, I think that recording a data type is a more straightforward
(or at least more easily understood) implementation.

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

Yes.

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

Well, okay for the first implementation.  :-)

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

Yes, but it would be nice to be able to pass in the version
numbers for column headings or the like, if the tool permits.

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

Yes.  Should the implementation support changing these values
after they've been set initially?  And are the set initially
at the time the RCS file is created or at commit time?

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

It's easier to set it when the file is created.  CVS already writes
RCS files in the proper format without using the rcs program to
initialize them.  The ci program doesn't permit the insertion of
newphrases in its present form, so there's no good way at present
to insert newphrases in the delta section of the RCS file at all.

>--- End of forwarded message from address@hidden