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 <[email protected]> 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 > _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
