On Fri, 13 Mar 2009, saurabh gupta wrote:
On Fri, Mar 13, 2009 at 12:23 AM, <david@xxxxxxx> wrote:
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)
yeah.
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.
I think picking up some formats and then building libraries above that
is needed. In some sense, I talked about the plug-in architecture
also. Can;t it be possible that for different applications (like OO or
SVG), different merge helper plugins are created which can be
integrated with it. Or speaking in other words, instead of plug-ins
now, libraries for merge helpers for different applications are
created.
defining terminology that was mentioned before
merge drivers are run by git to do the merges and create the conflict
markers. git already has a 'plug-in architecture' for these drivers (you
can define file types and tell git to use a particular merge driver for
this file type)
merge helpers are run by the users if there is a conflict and make use of
the markers. depending on what you end up using for conflict markers, you
may not need to write a merge helper (for OO, if your conflict markers are
good enough you can use OO to resolve conflicts easily, no need for a new
tool)
with this terminology, you can't do merge helpers without doing the merge
drivers first (what does the helper look for as an indicator of a
conflict?)
I believe that there is a lot of potential for a configurable merge driver
to support many similar formats.
using the example of XML-based files, configurable options could include
1. is the file stored compressed or not
2. does the order of the tags matter
3. does whitespace matter
note: #2 and #3 may boil down to 'is this a document with XML markup, or
are the XML tags the primary content'
4. how is the conflict marked
4a. wrap the conflicting tags in a set of tags that look like _
4b. if the conflict is in the content, not the tags, modify it similar to
what we do with text today.
note: this still requires the new driver to decide if there is a
conflict or not
4c. other (potentially including calling out to other code for more
drastic restructuring)
with a merge driver along these lines you can handle many different types
of XML documents.
with SVG you may be able to put the offending tags in different layers
with OO you may be able to put in tags that indicate a merge conflict in a
way that OO will directly handle
etc.
in many cases you may not even need to create a merge helper or library
for other software you use. you just need to figure out what sort of
manipulation would need to be done to to file to mark the conflict in a
way that existing applications can understand.
David Lang
