In 2D History of a directory, show merge arrows that affect its subtree
I often bring up the 2D history tree for a directory to see what changes are done to items in its subtree. This works quite fine, but it does not show merge arrows for merges that involve items inside the relevant subtree. This makes it harder to follow what happened.
For example, I can see "C" changesets on a child branch and then later a "C" changeset on the main branch where the comment on the latter says it was merged back from the child branch, but there is no merge arrow displayed.
For a more informative view, I suggest that for 2D history of a directory, merge arrows should be shown whenever a merge involves any of the items from that subtree.
Göran Wallgren commented
If you don't find this feasible, then please implement this instead:
That would be just fine, since most often we try to checkin clean merges anyway. If a subtree has changes in a changeset that is merged, most likely the merge is related!
Look, the problem with this is the cost of calculating the information. You need to expand each changeset, find all merge links to children, and so on. It would be a rather expensive operation, slow, which always means bad usability (slow == unusable).
Granted we could speed it up, but it would be certainly not something easy to do.
We'll keep an eye on this for a few weeks and if this idea gets traction we'll consider it, otherwise we'll discard it.
Göran Wallgren commented
Are you sure? My thinking is more along these lines:
For each changeset that is displayed in 2D History for a directory
-- If there is any (incoming) merge associated with that changeset
-- -- If the relevant subtree of that changeset is involved in an incoming merge
-- -- -- Display merge arrow for that changeset
* You ARE already able to (quickly) "Display all merges in history" (you have an option for this under "Version tree").
* You ARE also able to (quickly) display only the changesets where something "interesting" (i.e changed items) happens in the relevant subtree.
Therefore my request should not be a big performance hit, since you would only need to check subtrees of the "changesets with changes AND incoming merges" subset.
Also, if you make this an optional feature, the user can trade performance for verbosity.
(If this is not at all feasible, then as a second best variant I would wish for an option to always show merge arrows that are incoming on the "interesting" (C) changesets. This would cover also my other uservoice http://plasticscm.uservoice.com/forums/15467-general/suggestions/10439205-add-unrelated-merge-indicator-in-2d-history-and which we could then close.)
This discussion originated here:
Well, this one exceeds a little bit what we can realistically do considering performance constraints.
I mean, we would need to diff every changeset to figure out if there are revisions being merged that belong to your path. In order to do that, we would need to load each tree and find childrens of the directory there... Doesn't seem to be something we can do quick enough.
I won't discard it yet because maybe one day we can do it, but I don't think it is a good idea to keep tons of single-voted requests around forever... let's see if we get some more feedback and also what we can do.