Re: Google Summer of Code 2009: GIT

On Fri, Mar 13, 2009 at 12:23 AM,  [off-list ref] wrote:

On Thu, 12 Mar 2009, saurabh gupta wrote:

quoted

On Thu, Mar 12, 2009 at 11:30 PM, [off-list ref] wrote:

quoted

On Thu, 12 Mar 2009, saurabh gupta wrote:

quoted

=>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>

quoted

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.

quoted

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