Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


gweronimo last won the day on May 30 2017

gweronimo had the most liked content!

Community Reputation

4 Neutral

1 Follower

About gweronimo

  • Rank
    Advanced Member

Recent Profile Visitors

1,237 profile views
  1. 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.
  2. 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
  3. 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)).
  4. 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.
  5. @calbzam Are you able to reproduce the issue with the above detailed steps?
  6. 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
  7. 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.
  8. 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.
  9. 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
  10. 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 (
  11. 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.
  12. 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
  13. 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
  14. 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
  15. 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
  • Create New...