gweronimo

Oops, the above point I made was actually invalid - I had missed the "Set as default query" button that is still present in the new UI, under Advanced - Query in these views. (Possibly I missed it because the default query did not seem to be carried over from the legacy UI to the new UI?) BTW, there is no longer a keyboard shortcut (F5) for the "Refresh" button in all the main views - this should also be restored...

In the new UI there are still too many missing features from the legacy UI, making it way too early to remove the legacy UI entirely. Here are some of these, but there may be more that we'll discover if we are forced to switch to the new UI (which we have so far avoided, due to these omissions) : In the new Mergetool, there are no keyboard shortcuts for resolving conflicts (i.e for toggling to keep/discard the lines from src/base/dst respectively). In the Branches view, the "Tree view" option is missing, making a large hierarchical branch structure appear only as a (very long) flat list. After restarting the GUI, the Branches view no longer remembers which (Advanced) filter was last active - we have our own attribute filter that we want to see by default... NOTE: The same issue also exists in all the following views: Changesets, Labels, Attributes and Code Reviews! When switching between workspaces, the last active view in each workspace is not remembered - which makes for an unnecessary amount of clicking if we are jumping back and forth between a couple of repos. (NOTE: It would be great if the last active view in each workspace was also remembered after restart.) The display of branch@repo@server at the top, next to the workspace selector, does not include the full (hierarchical) branch name (except when hovering). That makes it harder to see full context at a glance. In Code Reviews, there is no longer any color coding of lines, based on code review status (Under review / Rework required / Reviewed). The new History view does not give the same at-a-glance overview as the old one, and the "History as 2D revision tree" view is missing entirely. See these posts: https://forum.plasticscm.com/topic/24022-history-is-the-one-thing-keeping-me-on-the-legacy-gui/ https://forum.plasticscm.com/topic/23127-view-history-as-2d-revision-tree-is-missing/ Pending changes can no longer be viewed as a hierarchical file tree, only as a categorized list. See these posts: https://forum.plasticscm.com/topic/22834-pending-changes-view-as-tree-instead-of-list/ https://forum.plasticscm.com/topic/23164-pending-changes-tree-view/ The Navigator / "minimap" option is missing from Branch Explorer - we find it valuable for overview and navigation. These were all great usability / workflow features that are now all of a sudden missing, since we can no longer access the legacy UI. Getting stuck on an old version is not really an option. Could you please retain the legacy UI for a while longer and prioritize re-implementing these missing features?

Hi! Nice work on unifying the UI for all platforms! Here are some initial thoughts, mostly around missing/broken parts that have become crucial to our workflow. Based on version 10.0.16.6479 : In the Branches view, the "Tree view" feature is missing! This is a showstopper for us, since we make heavy use of nested child-branches. After restarting the GUI, the Branches view no longer remembers which (Advanced) filter was last active - we have our own attribute filter that we want to see by default... On a related note, the display of branch@repo@server at the top, next to the workspace selector, does not include the full (hierarchical) branch name (except when hovering). That makes it harder for us to see context at a glance. In Branch Explorer, Options sidebar, Filters & format - the Enable checkbox is missing, so there's no way to see/change which filters are active. (NOTE: we use filters from plastic-global-config repo, so we don't want to delete filters just to temporarily disable them - which, by the way, causes "An unexpected error has occured".) Related to the previous point, it seems our inactive/disabled filters are still active in PlasticX, which makes it show fewer branches (in Branch Explorer) than the classic GUI does. The Navigator / "minimap" option is (so far) missing from Branch Explorer - we find it very valuable for better overview and navigation. In Branch Explorer, the "Display full branch names" option is missing - we use it to display more context (from the branch Comments field) while keeping task names short and task/ticket-based (T123 etc). In Branch Explorer, merge arrows are missing the excellent context menu of "Go to source/destination". Also, please add a similar context menu on the branch parent/child lines: "Go to base changeset / child branch" - this would be very helpful for navigation in cases where these lines are spanning far across and don't fit on one screen. After restarting the GUI, Branch Explorer starts scrolled towards the leftmost (oldest) changesets shown - it really should default to displaying the latest changesets (or possibly remember what parts were shown last). The Diff editor is missing the options for Tabs width and is defaulting to 4 spaces. This could be in Preferences, preferably as a number input (since the old implementation was restricted to only 4 or 8 spaces).

How we approach the second goal, in our workflow, is to (automated by a create-branch trigger) add a custom "branch-status" attribute to each branch. The default value of this attribute is "in-progress", and other values include "pending_review" and "completed" - we then use custom coloring and filtering based on this attribute. That way we can prune the Branch Explorer and Branches views to include only the active branches. Also, we've checked in the Branch Explorer rules for this coloring and filtering in the plastic-global-config repo, so all users get the same rules by default.

Sorry for delayed answer. The workaround is acceptable, but this problem needs to be documented! It's very easy to fall into this trap if using some command that does output in the trigger script. It's also very deceptive, since it may work at first and then (even years later) you hit the 4096 mark and BOOM the trigger hangs... The best solution would be if you could somehow prevent this issue in the Trigger system itself... Thanks, Göran W.

OK, here are example steps to reproduce: 1. On a child task branch, edit a read-only xlink to point to a later version that contains "breaking changes" to some code that is included in the build on the current repo. 2. Update the dependent code to build again, after adjusting to these breaking changes. 3. Switch to the parent branch and Merge back the child branch. 4. Now without Checkin, the merged-back code will not build (even though it probably should) - since the xlink still contains older code. 5. Checkin. Code will still not build in your local workspace. 6. Update workspace. Now at last the xlink is updated and the build will work. Regards, Göran

A variant of the originally mentioned problem becomes very apparent when performing a merge that includes a modified xlink-target-revision. If the updated xlink-contents are needed for the merged code to build correctly, then the build will fail and there is no way to verify the build BEFORE checkin of this merge. (Performing an Update is possible but it does not help, since the xlink-contents are not updated to the new revision (since the revision-change is not checked in)).

That is not what the OP was asking about. There is already a rudimentary URI support for the Plastic client GUI (at least on Windows), which you can see if you try navigating to plastic: in a web browser - it will open the Plastic client GUI.

@calbzam Are you able to reproduce the issue with the above detailed steps?

In case it helps anyone, there's a flag --cutignored that can be combined with --ignored to filter out the contents below ignored directories, thereby simplifying the output. The following command gives a list that can be used directly in a FOR loop : cm status --ignored --cutignored --compact --short

Hi there! This stumped us too. It seems this has still not been added to the documentation? We discovered by experimenting that the client-side triggers are not purely "client-side" but rather "server-provided client-executed trigger". Our first interpretation of the Triggers Guide was that we would need to setup a client-side trigger on each client machine, but we soon discovered that this led to *many* client-side triggers. ;D We then went back to the Triggers Guide and to our surprise we found no mention of this fact. This really has to be explained better! Best regards, Göran W.

Yes we have lots of ignored items, which is how I discovered this problem in the first place. But the [cm status --ignored] command is beside the point, since the issue appears even with a simple echo:ing for-loop. I'm not sure I was clear enough on how to reproduce the issue, so here's a more complete step-by-step description: Step1 - Create file echo_trigger.bat in workspace root: @ECHO OFF FOR /L %%n IN (0,1,1000) DO (ECHO "Just a lot of stupid text output") Step 2 - Verify that the echo_trigger.bat script outputs lots of lines when run. Step 3 - Setup client-side trigger: > cm trigger create before-setselector "echoing trigger" "@WKSPACE_PATH\echo_trigger.bat" Step 4 - Run the trigger: > cm switch br:/main NOTE: The switch command in step 4 does not terminate, seemingly since the trigger chokes on the amount of output to stdout from the script. (But if I decrease the loop limit from 1000 to 100 and re-run the switch command, it terminates fine.) Also, if you are really unable to reproduce the hung trigger - please make sure you are actually hitting the trigger, by adding a PAUSE command at the end of the .bat file. Then it should hang the trigger regardless... Best regards, Göran W.

In case it helps anyone, there's a flag --cutignored that can be combined with --ignored to filter out the contents below ignored directories, thereby simplifying the output. The following command gives a list that can be used directly in a FOR loop : cm status --ignored --cutignored --compact --short

Sorry to awaken this old thread, but this is still quite a problem! I just spent a couple of hours trying to understand why my client-side trigger (before-setselector) would hang often but not always. This trigger called a .bat file that in turn called [cm status --ignored] without redirecting the output to >NUL. You should be able to reproduce this issue using just a .bat file like this, called from a trigger: FOR /L %%n IN (0,1,1000) DO ( ECHO "Just a lot of stupid text output" ) For me, this .bat file hangs the trigger, but it no longer does if I decrease the loop number from 1000 to 100. This was tested on the very latest Plastic version (8.0.16.3937).

Yes, our use case is similar to the one in the blog. Looking at that example I see that something like that might work for us - but we also need to use partial xlinks, which are only available as read-only.

The proposed workaround by Manu would probably rarely be useful for writeable xlinks, while a similar (but working) workaround would be very useful for read-only xlinks. The whole point of my suggestions was for read-only xlinks only. Being able to update a read-only xlink without prior checkin would be very helpful indeed. The optimal workflow for us would be as follows: 1. Make changes in the xlink-target repo. Checkin. 2. In the xlinking repo, edit the (read-only) xlink to point to the new revision from the target repo. Update (refresh) its contents (without checkin). 3. Build and test. Make changes to the code that uses the xlinked content until everything works fine. Checkin. Without the ability to update/refresh a read-only xlink, in times of frequent changes to the xlink-targeted repo we'll get lots of "unnecessary" checkin+update cycles where the only change is an xlink edit. Also, there is no way to temporarily test an older/newer revision of the xlink, without first checking in and then later having to re-checkin the xlink edit. As for writeable xlinks, I would have to setup a branch expansion rule and I would then get automatic branching happening? This is something we don't want and that could possibly run out of hand since we have xlinks to the same repo in two different repos with different branching patterns. I'd like to hear your advice in this scenario. For example, is it possible to use writeable xlinks without automatic branching? Best regards, Göran W

Hi! There seems to be some usability missing when working with read-only xlinks. Having to perform a full cycle of [edit xlink] + [checkin] + [update] just to fetch a different (read-only) revision of the xlinked content seems both non-intuitive and counter-productive. The workflow would be much improved if there was an option to immediately update the (read-only) contents after editing the target changeset of the xlink. I understand that this can't be done for writable xlinks, but that is exactly my point! Since the two variants are not equal, the workflow around one should not be forced to mimic the other. The problem with having to checkin + update is that the rest of the code may be work-in-progress and we may need to make further changes due to the incoming updated xlink content. We'd like to be able to build and test with new xlink content without having to checkin first. The only problem I can foresee with such added functionality is that the user may have pending changes inside the read-only xlink folder. (These changes are quite useless since they can't be checked-in!) In this case, we could simply be warned that we need to revert these changes before editing (and refreshing) the xlink. I'm aware that a similar workflow could be achieved with writable xlinks, but that seems rather complicated due to branch expansion rules. It also seems unpredictable in our use-case since we have multiple repos xlinking to the same target repo, with different branch hierarchies in each. There have been some previous topics requesting this feature: NOTE: In the above topic a workaround was suggested for this scenario. However, I tested this idea and it no longer seems to work at all. I had to shelve my non-xlink changes and revert the experiment in order to get back to a workable state in my workspace again. Best regards, Göran W

Oh, and there are 2 related uservoices for the last suggestion: https://plasticscm.uservoice.com/forums/15467-general/suggestions/9588258-branches-view-add-submenu-branch-explorer-for-q https://plasticscm.uservoice.com/forums/15467-general/suggestions/5063260-add-branch-explorer-menu-to-branches-tab Thanks, Göran

Thanks for the meeting! To summarize, the following 3 suggestions are top on my wishlist regarding branch explorer: * Give an option to arrange the "Branch Explorer" layout vertically to mimic the "Branches - Tree view" hierarchy, with every children below its parent. * Make the "branch base" links (or "cross-branch changeset links") clickable with tooltip and context menu, just like the merge arrows. * Make the whole "Branch Explorer >" branch-context-submenu (Go to branch base, Show selected branches in a new diagram, etc) available in the Branches view as well. /Göran

@mig I think that could work. I'm in Sweden so same timezone... Best regards, Göran W.

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

@psantosl That leaves myself available for chatting, it seems. We could talk next week...

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.

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

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?