Re: [egit-dev] Tree compare

[Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx>]

2011/1/28 Kinzler, Mathias <mathias.kinzler@xxxxxxx>:
>> -----Ursprüngliche Nachricht-----
>> Von: Robin Rosenberg [mailto:robin.rosenberg@xxxxxxxxxx]
>> Gesendet: Donnerstag, 27. Januar 2011 22:53
>> An: Kinzler, Mathias
>> Cc: egit-dev@xxxxxxxxxxx
>> Betreff: Re: [egit-dev] Tree compare
>>
>> Kinzler, Mathias skrev 2011-01-26 09:28:
>> > -----Ursprüngliche Nachricht-----
>> > Von: egit-dev-bounces@xxxxxxxxxxx
>> [mailto:egit-dev-bounces@xxxxxxxxxxx] Im Auftrag von Robin Rosenberg
>> > Gesendet: Mittwoch, 26. Januar 2011 00:09
>> > An: egit-dev@xxxxxxxxxxx
>> > Betreff: [egit-dev] Tree compare
>> >
>> > There is a tree compare (again) in EGit. Why was it not done like this
>> > image (circa EGit 0.3)?
>> >
>> >
>> http://rosenberg.homelinux.net/wordpress/wp-content/uploads/2007/03/eclipse-
>> 20070318.png
>> >
>> > -- robin
>> > _______________________________________________
>> > egit-dev mailing list
>> > egit-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/egit-dev
>> >
>> > I tried to do something just like this (actually without knowing the
>> EGit 3.0 implementation), but couldn't find a way to integrate a
>> structure and compare editor. Any hint how to do this?
>> > _______________________________________________
>> > egit-dev mailing list
>> > egit-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/egit-dev
>> >
>>
>> That was fairly straigt forward. Essentally provide a Differences that
>> produces DiffNode:s. See the org.eclipse.compare.structuremergeviewer
>> packages and some old commit, like
>> 8bb1056a1d545eecef1cdca1f00100689e851bfd (can be found on repo.org.cz)
>
> Yes, I know the merge framework (I did the EGit merge tool with it [which I still need
> to do some performance improvements for]) and my first idea was to use it.
> But it seems to be impossible to add a toolbar or anything to the "Structure" part
> (which I guess is consistent with Eclipse UI guidelines, as we are looking at an Editor here)....
>
>>
>> My first version produced a tree for directories, but I think the
>> flattened view was an improvement. It is probably easier to make it
>> handle renames, which I think is a must. I'm not sure having a tree view
>> for the directories is compatible with rename detection at all.
>
> Good point. But Matthias already suggested to use a single tree instead of two
> trees side-by-side using tree columns to provide information; in this case, the rename
> would have to be visualized in some column; As for rendering the tree, we have
> looked at what kdiff3 does, and I think we should try to do something similar.
>
> Coming to think about it, we might even want to offer two options for compare,
> one similar to your previous implementation which would be list-based and be implemented
> using the merge framework and another one which is tree-based. UI-wise, the
> user could call the options "Tree Compare" and "Quick Compare" or something...
>
> I still think that the user should be able to do a tree-based compare, but believe the
> merge framework is not powerful enough for this.
>
>>
>> The structured diff was also many times faster than your diff. It
>> typically took way less than half a second to perform a full compare of
>
> That doesn't come as a surprise to me.
>
>> two versions. I also set focus back to the commit list so it was
>> possible to browse the history using the up/down arrow keys.
>
> I agree that for this use case in particular, the "Quick Compare" is much more
> usable.
>
> I guess we should look at a "quick compare" sometime soon...

I think somewhere here the old compare implementation started :
http://repo.or.cz/w/egit/chris.git/commit/1b66794e691d9614ef0005e9fdece89b915a8546

-- 
Matthias