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. -- Saurabh Gupta Senior, NSIT,New Delhi, India -- 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
