Once again, take a look at message ID# [EMAIL PROTECTED] posted to this forum on September 16, 2001. It illustrates one way (though perhaps not the best way) to do just this. It relies on a lookup table that looks up a diff tool given a file's name.
A better implementation would be to code a symbolic name for the merge tool in a newphrase in the admin section the RCS file, and look up that symbolic name on the client to locate the proper tool. >--- Forwarded mail from [EMAIL PROTECTED] >> A better approach is to avoid XML entirely in the first place >> -- it's a >> really really horrid syntax with all kinds of goo that's usually way >> over-kill for the application, being SGML based and all that.... >I agree that XML is overkill, but the truth is that it is here to stay. >XML is fastly becoming excepted as the defacto standard for data exchange. >Opto 22 makes machine control sensors / PLC that publishes data in XML. >Semen's is doing similar things from what I understand. Java uses XML for >all of the enterprise application descriptors. It seems that I can't >interface to machines, or program without looking at XML. >If CVS had away to use modular plug in "diff" and "merge" programs, we could >setup a wrapper file that would automatically diff/merge the file >differently based on the extension. e.g.: >*.xml xml_dm >*.html html_dm >This way we could write our own diff programs without having to understand >all the complexities of tying into CVS code seamlessly. Interfacing is much >easier. We could even take the XML diff/merge programs that are already >available and just write wrappers for them. No point in reinventing the >wheel here. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
