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