Re: [feature request] tree iteration order option

[Karl-Philipp Richter <richter richtercloud de>]

Hi,
In the meantime (after a long disappointing search for better
interactive merge tools - `meld` really is the best :) ) I found out
further implications of the search order and suggest a review this time
in conjunction with optional lazy tree expansion:

`meld` (3.12.0) wastes huge amounts of memory when used as directory
merge tool because it reads all files in a directory which one might
just want to copy to the other side completely and without reflecting
its content. Imagine an invocation of `meld a b` where `a` and `b` are
directories with `1` (2 files, 3KB), `2` (5M files, 700 GB) and `3` (3
files, 4KB) in `a` and `1` (5 files, 2KB) and `3` (3 files, 3KB) in `b`.
What happens? `meld` crashes after allocating > 10 GB RAM because it
reads `2` recursively before allowing comparison of  of the two version
of `3`. I thinks it's a pity that the application (again, it's really
great :) ) doesn't cover this use case and it would be a great improvement.

Allowing comparison of `3` before `2` is read would be great already,
even better would be optional(!) lazy expansion of the tree, e.g. of the
very large `2` causing enormous swapping.

I understood the point that changing the tree iteration order is
difficult to change.

Best regards,
Kalle

Am 30.12.2013 um 22:15 schrieb Kai Willadsen:
> On 30 December 2013 23:37, Karl-Philipp Richter <krichter722 aol de> wrote:
> > Hi together,
> > Another feature request: Providing an option for the tree iteration
> > order, i.e. depth first or breadth first. Currently the tree is built
> > depth first which has the disadvantage that the tree can only be
> > explored from one start point during its construction. I don't know
> > whether this (exploring the tree during its construction) is a specified
> > feature of meld, but it seems to work pretty well anyway. If we just
> > assume it would be, the user might explore a subtree and find a
> > directory in this subtree which he/she wants to copy to the other side,
> > so that the comparison for this subtree can be aborted because trees
> > will be identical after copying. In a depth first search larger subtrees
> > are made available earlier so that the profit from the described
> > mechanism can be increased.
>
> I think the short answer to this is that this really isn't a supported
> use. I'm not shocked that it works, but I really wouldn't like to
> guarantee that any actions would necessarily work as expected until
> the tree is fully loaded.
>
> Either way, we have some assumptions built-in to the tree construction
> that rely on us doing a depth-first search, so it's not possible to
> change the iteration order easily anyway.
>
> cheers,
> Kai