Google Summer of Code 2009: GIT

[saurabh gupta <saurabhgupta1403@gmail.com>]

hi,

On Fri, Mar 20, 2009 at 5:12 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 20 Mar 2009, saurabh gupta wrote:
>
>> On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > For example, if we decide that OOXML is a must (as it is a proper
>> > standard, and many people will benefit from it), we will most likely
>> > end up in having to write a merge _driver_ (to handle those .zip
>> > files), _and_ a merge _helper_, although we can avoid writing our own
>> > GUI, as we can create an OOXML that has its own version of conflict
>> > markers.
>>
>> Well, for ODF type document, we can write a merge driver which will
>> change the xml file in an appropriate way that OO can understand it and
>> the user can see the merge result/conflict in a comfortable way. As
>> described by Junio, in this case, a dedicated merge helper is not needed
>> as OO can parse the markers made by merge-driver and provide the user to
>> resolve the conflict and register the changes to index.
>
> There is also the idea that OOffice has building blocks in place to help
> resolving merge conflicts.  For a successful application, you will have to
> show that you researched that option, and describe how well/badly it fits
> with the goal of the project.

Exactly, I will have to do some research on it and I will come back to
you as I get over with my college's mid-semester exams (this week
more).

>> > - knowing what data types we want to support _at the least_, and what
>> >   data  types we keep for the free skate,
>>
>> As of now, how about going for XML files. For this summer, we can go for
>> XML files and latex files can be handled later.
>
> If your goal is just XML files (without any more specific goal, like ODF
> or SVG), I am afraid that I think that project is not worth 4500 dollar
> from Google's pocket.  I mean, we are not talking peanuts here.

Well, I didn;t mean to say that we will end up in only having a merge
driver for xml after the summer. We will definitely make the driver in
such a way to use the maximum power of xml manipulation so that the
end application can understand it and user can get the conflict
results in a user friendly manner because the end-user application wil
be able to parse the merged xml file and will present the conflict
markers in the GUI form.


>
>> > - a clear picture of the user interface we want to be able to provide,
>>
>> In my opinion, we have following things to do:
>>
>> => while merging an ODF document, merge-driver will merge the file at
>> file level. If changes don't overlap, then it returns the result with
>> a success. For example, if the file is changed only on one side, then
>> the driver will simply add the new content.
>>
>> => If conflicts appear, then the merge driver will put the markers in
>> an appropriate manner which the end-user application (e.g. open
>> office) can understand and show the user. For example, the XML file of
>> that ODF document will be modified and OO can show it  to user in its
>> way. We will have to study about the OO style of version marking.
>> Another method is to implement the marker style in our own way. For
>> example, to show any marker, the XML file is modified so that user can
>> see markers like ">>>> " or "====" in openoffice....In this case, we
>> will have to just change the xml content in this way.
>
> That is correct, but I would appreciate a bit more definitive research
> _before_ the project proposal, as a sign that you are capable of working
> out the details of the project.

I do understand your point and will work this.

>> > - a timeline (weekly milestones should be fine, I guess) what should
>> >   be  achieved when, and
>>
>> Timeline can be decided once we reach some conclusion and the work which
>> needs to be done become clear to us.

I meant to say that time line can decided after the list of works is
decided and discussed. Of course, I will present the timeline in my
student application in GSoC 2009. :)

> Do not get me wrong, I want this project to succeed.

I will try my best.

> But on the other hand, I feel the obligation to be a bit demanding for the
> gracious donation of Google: we _do_ want to have something stunningly
> awesome at the end of the summer.
>
> And that means that I have to get the impression from the student proposal
> that something like that is at least _possible_.
>
> Ciao,
> Dscho
>



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