On Fri, 13 Mar 2009, saurabh gupta wrote:

> On Fri, Mar 13, 2009 at 12:23 AM,  <david@lang.hm> wrote:
>> On Thu, 12 Mar 2009, saurabh gupta wrote:
>>
>>> On Thu, Mar 12, 2009 at 11:30 PM, <david@lang.hm> 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