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.