Re: Google Summer of Code 2009: GIT

Hi,

On Fri, 20 Mar 2009, saurabh gupta wrote:

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.

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.

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.

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.

Last year, most successful applications detailed a proposed timeline in 
their proposal...

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

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