Re: Google Summer of Code 2009: GIT

[saurabh gupta <saurabhgupta1403@gmail.com>]

On Wed, Mar 11, 2009 at 9:08 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > On Wed, 11 Mar 2009, saurabh gupta wrote:
>> >
>> >> What I think is to implement file formats other than text like that
>> >> written on wiki i.e. latex, xml, or even any database file (db file).
>> >> Another idea (although it can be weired also) is to implement the new
>> >> file formats in the plug-in formats. For example, to incorporate the
>> >> merger engine for a new file format, a plug-in is created and can be
>> >> integrated with the present merger in the git. However, I am not sure
>> >> how much valid is this idea to make the present merger in git to be
>> >> compatible with the plug-ins for enabling newer file formats.
>> >
>> > I am not sure that a plugin structure is needed.  Take, for example,
>> > three different .xml based formats: OpenOffice documents, .svg files
>> > and Ant build.xml files.  They need very different user interfaces.
>>
>> okay. In that case, if they have a different user interfaces then
>> separate plug-in would be needed for each of these. May be this will get
>> more messy.
>
> The thing is: "plugin" is an architecture issue, which I think we will
> have plenty of time hashing out.  "GUI" is the bigger problem, because if
> we cannot come up with something that is worth implementing, we can stop
> the project early.

We can decide for the GUI part. RIght now, I am going through the
background for Tcl/Tk. I am sure that using this tool will serve the
purpose in the better way and portability issue can also be kept in
mind.


>> >> However, I think in merging and notifying about the conflicts in the
>> >> xml files, other things can also be put forward. Like the GUI will
>> >> show the number of tags differing and what are the new tags added and
>> >> even if any tag is renamed with the content unchanged. If possible,
>> >> how about showing a tree like structure (just like DOM model) to
>> >> compare (or diff) the two xml files.
>> >
>> > This is a little bit too low-level for my liking.  Taking the
>> > OpenOffice example again, the GUI should not expose XML at all...
>>
>> hmmmm.....I think I get your point somewhat. Let me do some research
>> over the formats and the background formats in which tools like
>> OpenOffice store the data in xml files. May be for docbooks by
>> OpenOffice, the best thing would be to give the *diff* output in terms
>> of lines.
>
> Actually, I think that the diff is not the issue.  What is needed is a way
> that is both intuitive and versatile enough that all kinds of merge
> conflicts in OpenOffice documents can be resolved by a total computer
> illiterate.
>
> The same problem applies for SVG files, but the user interface would look
> completely different.
>
> As such, it might not be wise to have a common framework at all, but to
> make the first an extension for OpenOffice, and the second a modification
> of, say, inkscape.
>
> Of course, David will then come and say: "But that is more appropriate a
> project for OpenOffice and inkscape, then!".
>
> The good thing is that this is Open Source, and we'll just ask them to
> co-mentor this project.

All right. I agree with this and We can come up with a plan to
implement the thing in an organized way. I agree with you that one
common platform for these will not work because of the way they are
represented and is comfortable for a normal computer user.

>> I would also appreciate to know what you think and would like to see the
>> output in such case.
>
> That's the thing: I do not know yet how it should look like.
>
> Ciao,
> Dscho
>
>



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