info-cvs
[Top][All Lists]
Advanced

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

Re: merge mode for XML


From: Paul Sander
Subject: Re: merge mode for XML
Date: Tue, 30 Apr 2002 10:21:56 -0700

I'm looking into a ground-up rewrite of CVS from Dick Grune's last shell script implementation. It will take a while to complete a prototype because my life is pretty turbulent right now, but it will get done.

On Tuesday, April 30, 2002, at 05:43  AM, address@hidden wrote:

Thanks for offering up the samples Paul.  I read through last Septembers
thread on "giving up cvs". I see that I stirred up an old debate here (man
you guys really had it out last time ;).

With the emergence of xml more and more programs are supporting it as a
format. If a cvs - xml diff/merge solution was implemented then cvs could
capture a huge new level of concurrent development in documentation,
configuration, and help system docs, etc...

Any chance some of you cvs wizes could ever implement a modular diff/merge subprogram architecture into CVS. Then we could implement an XML wrapper.

sean.


-----Original Message-----
From: Paul Sander [mailto:address@hidden
Sent: Monday, April 29, 2002 12:43 PM
To: address@hidden; address@hidden
Subject: RE: merge mode for XML


Once again, take a look at message ID#
address@hidden
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 address@hidden

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 address@hidden




reply via email to

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