Jump to content
mig

Dynamic Branch Explorer Layout

Recommended Posts

Hi all!

We're going to release a new feature to make the Branch Explorer diagrams more meaningful. The layout will order branches acknowledging your current workspace status, moving to the top the branches you're more likely to use. We'd love to hear your feedback about this, so we're opening this thread to provide a link in the upcoming release notes when the first layout changes are published.

We'll post a new message in this thread when the new feature is released.

We can't wait to hear your thoughts!

Share this post


Link to post
Share on other sites

I really appreciate that you work on this!¬†ūüėĀ

Does the manual relayout still work with the dynamic branch layouting?

Because I really like to have a ordered structure on my branch explorer. This and branch colors help me to find the correct branch really fast!

I'll try the new dynamic branch layout. But I think it will still be too 'unorganized' for me.

I posted this user voice some time ago, suggesting a custom rule set for branch weights: 

https://plasticscm.uservoice.com/forums/15467-general/suggestions/18561949-add-a-branch-weight-for-layouting-in-branch-explor 

You could integrate the dynamic layout into this system as well ;) Just add rules for hierarchy level, recent activity and live span.

 

Share this post


Link to post
Share on other sites

Hi guys! Thanks for your feedback.

The dynamic layout is still in a really early stage, so we're absolutely open to suggestions and it'll probably change in the future.

Answering @SWSBB: yes, this functionality is compatible with manual relayout. Regarding the weights system, I'm happy to tell you that we're already weighting branches according to their relevance in the chart. We're just doing it in a basic way at the moment: main > top-level > parents of workspace branch > workspace branch > children of workspace branch > other branches > integrated branches. We'll take good note of your thoughts on the matter for the next iteration of the dynamic BrEx layout ūüėČ

 

@jwvanderbeck: I'm afraid yes, the /main branch will always be on top using this dynamic layout. That /main branch always has GUID '5fc2d7c8-05e1-4987-9dd9-74eaec7c27eb', and that's what we move to the top. Then you'll have any other top-level branch beneath it, which might still be useful to you: from what I understand, your /develop branch merges into /main eventually, right? I'll let the team know about your setup to see when we can provide you a way to specify your top-most branch!

Thank you so much for your feedback!

Share this post


Link to post
Share on other sites

@SWSBB how would you like to enter weights in branch attributes? Would that make sense?

We could also use some file to give weights, but then people would complaint about GUI support.

If we end up implementing custom weights, we could simply use a brex_weight special attribute that you can use for this.

@mig any other idea you'd like better?

I'm not sure it would be a widespread feature, anyway, because users need to configure their stuff.

@jwvanderbeck this would also fix your "main" issue, I believe. But, in your case, you can easily move develop up with the relayout, right? @S_Luis can we put the relayout in global config already? Or is that yet in the wish list?

Share this post


Link to post
Share on other sites

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) :
plastic_tangle.thumb.png.1d224166684a3a0f185fb558fb6216a6.png

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

Share this post


Link to post
Share on other sites

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!
;)

Share this post


Link to post
Share on other sites

First off, never do this:
plastic_crossing.png.73f3936b32a9d8e14f490955ba6b06be.png

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

Share this post


Link to post
Share on other sites

Second, don't do this:

plastic_children.thumb.png.bb964438edddfacc61f233efee7b05e9.png

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:

plastic_family.thumb.png.fe752da66cf13a8a16142eff121e591f.png

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

Share this post


Link to post
Share on other sites

And this is how I suggested the 2D bounding boxes to be calculated:

plastic_bounds.png.a67c39e61d2fbabdcc461538213fe67e.png

As you can see the AABB on each level includes:
* the branch itself,
* all descendants (updated vertically during layout),
* and (only horizontally) the branch-base changeset from the parent branch.

EDIT: Interestingly, the two immediate child-branches here can not be individually sorted since they have the same "left bound" (same branch-base-changeset). We'd need to use some other heuristic here to choose between them...
* Just pick one?
* Smallest box-width first? 
* (Smallest box-height first? - Not available until after layout is done!)
* Lowest number of child-branches first?
* Start with the branch where the first changeset on the branch has the latest timestamp/revision?

Share this post


Link to post
Share on other sites
9 hours ago, mig said:

 

@jwvanderbeck: I'm afraid yes, the /main branch will always be on top using this dynamic layout. That /main branch always has GUID '5fc2d7c8-05e1-4987-9dd9-74eaec7c27eb', and that's what we move to the top. Then you'll have any other top-level branch beneath it, which might still be useful to you: from what I understand, your /develop branch merges into /main eventually, right? I'll let the team know about your setup to see when we can provide you a way to specify your top-most branch!

Thank you so much for your feedback!

Bear in mind I'm coming from a Git background so it might be we should change our way of thinking, but it is currently as such.

Tasks are done in branches off develop (eg /master/developer/scm10), and this lets us do integration in /master/develop.  Alpha (and probably beta) releases can can then be cut from /master/develop by doing a GitSync which then kicks off a Unity Cloud Build.  Then, certain alpha/beta builds will be "promoted" to the /main branch as full releases.  So for us /main/develop is sort of like a fast ring, and /main a slow ring.  This works well with Unity Cloud Build as well because I can have different build configurations for /master and /master/develop so for example all builds coming from /master/develop are build as development builds with extra debugging, whereas those coming from /master are not.

Right now we are just starting the project and in early prototyping, so all builds are getting integerated back to /master/develop and built as alpha builds.

plasticbranches.thumb.png.5b22e50e46bcea32c2d1fddaf0865cc0.png

The red is /master and the blue is /master/develop

Share this post


Link to post
Share on other sites

NOTE: If my suggestions above seem like too much work, a good start would be to (optionally?) arrange the branches just like the Branches Tree View, without the additional requirement of "no crossing base-links"...

Share this post


Link to post
Share on other sites

@psantosl I'm fine with a custom branch weight attribute. We use a lot attributes already to filter the branches and stuff. We can also implement our own rules this way, as they are all the same for everybody.

But I think there will be users that have different needs. Then fix branch weights might not be good enough. I thought of  'conditional weights'. Just like conditional colors. Maybe add a multiplyer for branch hierachy level and a reference for the parent branch weight. Then allow it to be a formular like: ([ParentWeight]*10)+1. Make sure that the basic operators (+-*/%) are supported. (I know this is tricky, as the parent branch doesn't have to be in the diagramm, but you still would need to calculate the weight for it. Maybe use promises, to only calculate it when needed?)

This should open the door for any custom layout.

 

I also like the bounding boxes suggested by @gweronimo.

But in our case this will not work. As I descriped in the user voice linked above: We order the branches in the branch explorer to mirror the release pipeline. So at the top are hotfix-branches, then releases and the release-candidate, then main (Trunk in our case) and then all the issues and features. This is our main repo. But there are other repos, where the bounding boxes would make a lot more sense. You already moved the branch explorer config to the workspace. So the¬†boxing sould be a layout option and then it's fineūüėÉ

I think you wouldn't even need an extra boxing algorithm if there was one more reference for the conditional weight formular: IndexOfChildBranch. Then a formular like this would handle the boxing: ([ParentWeight]*100)+[IndexOfChildBranch]. The newest child branch should have the Index 1 and older branches get a heigher index. Then the boxing would be handled by just that ;)

What do you think?

Share this post


Link to post
Share on other sites

Well, for us the most basic and non-negotiable requirement (in order to get a decent overview) is that a child branch is always rendered as close below its parent as possible without overlapping siblings, which I guess would make perfect sense in any tree layout.

If you look at my "don't do this" screenshots, the "child above parent" and "children dispersed among unrelated branches" layouts just don't make much sense at all and seem rather randomly arranged just to make use of empty space.

Share this post


Link to post
Share on other sites
On 10/25/2019 at 10:54 AM, psantosl said:

No, I mean this @S_Luis

image.png.aa9788634324c1e77af5becf1718e0c0.png

The relayout config, where you can manually move branches, if this can be shared with all users.

 

The relayout and visibility configuration files are simple and portable, so I think we can safely share them through the plastic-global-config repository to all users.

Share this post


Link to post
Share on other sites

I'm sorry. I'm in Japan right now with a lot of time difference and no stable internet connection. But please go ahead and discuss this with the other guys ;) 

Share this post


Link to post
Share on other sites

I have two uservoices closely related to this discussion:

https://plasticscm.uservoice.com/forums/15467-general/suggestions/9655032-improve-vertical-ordering-in-branch-explorer-make

(Yes, I've been mumbling about vertical branch ordering since 2015... ;)

https://plasticscm.uservoice.com/forums/15467-general/suggestions/33870115-branch-explorer-make-cross-branch-changeset-link

(This one is about consistency and usability - it would be very useful if the branch-base-link was a clickable object just like the branch arrows, with tooltip info and context actions!)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...