Re: Google Summer of Code 2009: GIT

[saurabh gupta <saurabhgupta1403@gmail.com>]

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.


-- 
Saurabh Gupta
Senior,
NSIT,New Delhi, India