Google Summer of Code 2009: GIT

hi,

On Fri, Mar 20, 2009 at 5:12 AM, Johannes Schindelin
[off-list ref] wrote:

Hi,

On Fri, 20 Mar 2009, saurabh gupta wrote:

quoted

On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin
[off-list ref] wrote:

quoted

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).

quoted

quoted

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

quoted

quoted

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

quoted

quoted

- 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