gweronimo

Second, don't do this: Here, the marked branches should be rendered together "as a family" with hierarchy intact, before the rest of the unrelated branches are rendered. Using "relayout mode" I sketched how I'd like this layout ordered instead: Immediate children are rendered first, no crossing branch-base-lines (or "cross-branch changeset links" as these are called in the UI). (NOTE: the "no crossing " criteria could be slightly relaxed, as long as the children immediate child-branches are still sorted by base-revision and rendered roughly from right-to-left.)

First off, never do this: The almost vertical branch-base-line here goes up instead of down (all child-branches should be below parent) and it crosses several branches (it shouldn't) and it crosses several other branch-base-links (it shouldn't).

TL;DR? * Always (recursively) put each child-branch as closely below its parent as possible (while avoiding overlap)! * Don't let any branch-base-line cross any branch or any other branch-base-line! ;)

Hi, I'm happy to see that you are finally starting to do something about the branch ordering in Branch Explorer. Ideas about custom weighting/relayout are all good, but in our case we don't want to tweak this manually - we need options that give us a sensible automatic default layout. We have in total approx 2000 branches and we use attributes to filter the currently/recently active ones (down to approx 60+ branches). I really like the hierarchical Tree View in the Branches view, since our branches are always nested in several levels, like /main/project1/feature1/task1/ or /top_level_release_branch/product1/release1/. I attached an out-zoomed image of our most recently active branches, with your new experimental layout activated (the green branch is the active workspace) : As you can see, the many crossing base-links makes it hard to get an overview of how these branches are related to each other in the branch-tree. With this in mind, it's also clear that having the workspace branch on top is not optimal for us. We'd much rather have a consistent Branch Explorer layout that mimics the hierarchy from the "Branches : Tree View" quite closely, and thus the workspace branch should stay in it's logical position in the tree hierarchy. I understand that the layout problem is not trivial, since child branches are overlapping in time and you still want the graph to be as compact as possible in the vertical direction... However, I think the following rules would fit the bill for us: * Assume that the Branch Explorer layout is horizontal (as is the default in Plastic). * For each top-level branch (in alphabetical order, optionally with /main always at the top), put all its immediate child-branches in a separate 2D bounding-box just below that top-level branch. * Recursively, for each sub-level parent-branch, put all its immediate child-branches in a separate 2D bounding-box just below that parent branch. * Where sibling-branches are overlapping, arrange them so that their 2D bounding-boxes do not overlap. * A parent-child link-line should never cross any branch - to achieve this, include the horizontal position of the "Go to branch base" (parent-link) changeset in the 2D bounding-box of each branch! * (Allow merge arrows to cross branches without restrictions - they need not be taken into account for layout.) * The 2D bounding-box for each branch should also bound all its (layouted) descendants. NOTE: horizontal bounds are fixed and can be calculated before starting the layout, while vertical bounds depend on the (recursive) vertical arrangement of descendants. * To layout child-branches, sort them by their "left bound" and always pick the one with the right-most "left bound" available. Greedily place the ones that don't overlap any other sibling horizontally, before stepping down vertically to avoid overlap with the remaining child-branch boxes. Recursively layout each placed branch and update its vertical bound before placing the next one. While this method may give a slightly larger graph in the vertical direction, I think it will be much more "readable"... Avoiding any overlap of accumulated parent boxes is probably enough for starters and simpler to implement, but overlap testing could be made more advanced by looking at individual leaf bounding boxes. (Basically, once initially placed, a branch with all its descendants could be allowed to "slide" upwards until any of its leaf boxes collide with another leaf box.)

Hi @manu, Yes, but have you thought about my comments regarding the internal effects of a "add-cherrypick-mergeback" cycle, where the last step results in a seemingly empty merge changeset that apparently resolves the issue for further merges? I think it contains important hints for how to improve this... Best regards, Göran

Hi Plastic team! I'm awakening this thread since I never got a comment on my findings from my last post, and since we again stumbled on this issue today (with latest stable version 6.0.16.1765 on Windows)... Cherry-picking added files is still problematic, and seemingly unnecessarily so! /Göran

Hi Manu! I want you to pay special attention to my very last comment. It means that there is a possible workaround in some cases: After a cherry-pick involving added items, immediately do a normal merge back onto the original branch (the one you cherry-picked from). Of course, this is not always feasible and it will NOT help if the added files have already been modified on the original branch. Please think through what happens in that merge-back, as it will not seem to contain any changes but still it will make subsequent merge-backs work fine even when there are changes to the added items on both branches (no more "item loaded twice"). These hidden details that happens in this "magic" (seemingly empty) merge-back is exactly what I'd like you to do in the original cherry-pick, so we don't get this problematic issue in the first place... Thanks, Göran

Hi! I'm awakening an old thread since it's related to the above mentioned uservoice. Would it not be possible to handle _added_ files/folders in a better way in a Cherrypick? When cherrypicking a file Add operation, a sensible expectation is to be able to merge this back to the branch where the Add came from... Fixing this would solve parts of this related uservoice. Here's a scenario: * Switch to branch /main * Add file a.txt. Checkin (1). * Add file b.txt. Checkin (2). * Switch to branch /other * Merge from (1). Checkin (3). "Copied (new) / Merge from 1". * Cherrypick from (2). Checkin (4). "Copied (new) / Cherrypick from 2". * Modify the contents of a.txt and b.txt. Checkin (5). * Switch back to branch /main * Modify the contents of a.txt and b.txt. Checkin (6). * Merge from (5). Now, you get a "Item loaded twice conflict" on b.txt that was cherrypicked earlier. On a.txt that was merged earlier you get no such problem, only a normal conflict. Could not the Cherrypick operation be modified to include the necessary info to be able to merge it back later? If we had done a (no-change) Merge from (4) back to /main before the modify-checkin (6), the following merge from (5) would have worked just fine. That seems to indicate that not much extra info is needed to get it working as expected. Thanks, Göran