Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Tree compare

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

> 
> -- robin


Back to the top