mig Posted October 22, 2019 Report Share Posted October 22, 2019 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! Link to comment Share on other sites More sharing options...
SWSBB Posted October 24, 2019 Report Share Posted October 24, 2019 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. Link to comment Share on other sites More sharing options...
jwvanderbeck Posted October 25, 2019 Report Share Posted October 25, 2019 Is this new system hardcoded to consider main the trunk? All our development at this time pretty much treats develop as the trunk until later in the product cycle. Link to comment Share on other sites More sharing options...
mig Posted October 25, 2019 Author Report Share Posted October 25, 2019 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! Link to comment Share on other sites More sharing options...
SWSBB Posted October 25, 2019 Report Share Posted October 25, 2019 This is good news 😃 Made my day. Thanks Link to comment Share on other sites More sharing options...
psantosl Posted October 25, 2019 Report Share Posted October 25, 2019 @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? Link to comment Share on other sites More sharing options...
S_Luis Posted October 25, 2019 Report Share Posted October 25, 2019 @psantosl This is a client.conf flag, not a branchexplorer.conf flag. We can't put it in the global configuration. Link to comment Share on other sites More sharing options...
psantosl Posted October 25, 2019 Report Share Posted October 25, 2019 No, I mean this @S_Luis The relayout config, where you can manually move branches, if this can be shared with all users. Link to comment Share on other sites More sharing options...
gweronimo Posted October 25, 2019 Report Share Posted October 25, 2019 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.) Link to comment Share on other sites More sharing options...
gweronimo Posted October 25, 2019 Report Share Posted October 25, 2019 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! ;) Link to comment Share on other sites More sharing options...
psantosl Posted October 25, 2019 Report Share Posted October 25, 2019 Wow! Quite detailed. Could you draw (by hand if needed) how do you imagine the resulting Branch Explorer? I'm super interested @gweronimo Link to comment Share on other sites More sharing options...
gweronimo Posted October 25, 2019 Report Share Posted October 25, 2019 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). Link to comment Share on other sites More sharing options...
gweronimo Posted October 25, 2019 Report Share Posted October 25, 2019 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.) Link to comment Share on other sites More sharing options...
gweronimo Posted October 25, 2019 Report Share Posted October 25, 2019 And this is how I suggested the 2D bounding boxes to be calculated: 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? Link to comment Share on other sites More sharing options...
jwvanderbeck Posted October 25, 2019 Report Share Posted October 25, 2019 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. The red is /master and the blue is /master/develop Link to comment Share on other sites More sharing options...
gweronimo Posted October 26, 2019 Report Share Posted October 26, 2019 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"... Link to comment Share on other sites More sharing options...
SWSBB Posted October 27, 2019 Report Share Posted October 27, 2019 @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? Link to comment Share on other sites More sharing options...
gweronimo Posted October 28, 2019 Report Share Posted October 28, 2019 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. Link to comment Share on other sites More sharing options...
S_Luis Posted October 28, 2019 Report Share Posted October 28, 2019 On 10/25/2019 at 10:54 AM, psantosl said: No, I mean this @S_Luis 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. Link to comment Share on other sites More sharing options...
psantosl Posted October 29, 2019 Report Share Posted October 29, 2019 Would you guys @gweronimo @SWSBB @jwvanderbeck like to have an online meeting next week and we talk about your proposals in person? We'd do a GotoMeeting or something. Link to comment Share on other sites More sharing options...
SWSBB Posted October 29, 2019 Report Share Posted October 29, 2019 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 Link to comment Share on other sites More sharing options...
jwvanderbeck Posted October 29, 2019 Report Share Posted October 29, 2019 I have no proposal, simply wanted to illuminate how I am currently working given it seems different from what is expected. Do with that information what you will Link to comment Share on other sites More sharing options...
gweronimo Posted October 29, 2019 Report Share Posted October 29, 2019 @psantosl That leaves myself available for chatting, it seems. We could talk next week... Link to comment Share on other sites More sharing options...
gweronimo Posted November 1, 2019 Report Share Posted November 1, 2019 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!) Link to comment Share on other sites More sharing options...
SWSBB Posted November 4, 2019 Report Share Posted November 4, 2019 @gweronimo totaly agree 😃 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now