On Thu, 12 Mar 2009, saurabh gupta wrote:
On Thu, Mar 12, 2009 at 11:30 PM, <david@xxxxxxx> wrote:
On Thu, 12 Mar 2009, saurabh gupta wrote:
=>Merging of two xml files
=> existing merge driver (like xdl) is called which marks the
conflicts points just like a normal text file.
=> the conflicted file can be read through a text terminal and
conflicted lines can be seen.
=> suppose the xml file is from the domain of OO document. Then, a
merge helper for OO xml type file is called which takes input as the
conflicted file produced by xdl driver.
=> The merge helper creates a new file or changes the input file to
make it a valid xml file so that it can be opened in OpenOffice and
user can see the markers like "====" or "<<<<<" in an appropriate
manner and can resolve the file manually.
with XML files it's possible to be symanticly identical, but not identical
as far as a text merge driver is concerned.
<SNIPB>
you are right. For xml merging, what I am thinking is to create the
algorithm based on the document object model. Inside, any tag, all tags are
compared only in terms of content and not in order. But again, this ordering
option can be given to the user. If the user wants order to matter, then a
conflict will be resulted if order mismatches.
right.
But other issue is regarding the display of conflict markers. Either
conflict markers should be put in xml format or like text merger. This is
the main project idea for GSoC 2009.
this may need to be a configurable option, but I suspect that we could get
away with always using something in XML format. exactly what the markers
are needs to be configurable (the markers for OO will not be the same as
for SVG for example)
building a library of 'this works especially well for this app' markers is
something that needs to be started as part of the GSOC project, but
possibly only far enough to show a couple of examples and have confidence
that the tool is configurable enough.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
