I encountered on several occasions already that what was displayed in pending changes did not match the actual state of files being committed. The reason being that changes are not automatically updated in the UI, but upon commit new changes are automatically collected using default behavior of changed files being committed, added, moved and deleted files must be selected manually - meaning the latter will not be part of such commit. The minimum thing that could be done is to notify the user that there are undisplayed changes that need to be reviewed. Even better would be to add git like staging of changes. I concede that this issues don't occur often and are a case of user being sloppy, but I would also point out that the workflow imposed by the UI doesn't help the situation. In my opinion gitextensions solves this problem nicely and clearly.

The "cm patch" command is able to yield diffs in the standardized "unified diff" or "unix patch" format as console output. However, there is no simple way to yield the same kind of console output for the Pending Changes.

Our Linux users are demanding this, and they are surprised that it is not currently possible since they are used to this behavior from "cvs diff", "svn diff", "hg diff" and "git diff".

We suggest adding this functionality to the "cm patch" command. All that's needed is to output the same kind of "unified diff" as usual, but based on the diff of the current pending changes in a workspace. Either by adding another option flag to the "cm patch" command, or by simply calling it without arguments.

If you are in a branch with some un-submitted files and you don't want to submit them into your branch yet. If would be great to be able to select the files you want and submit them directly into another branch but keep you in your existing branch. We work with not allowing people to switch branches with pending changes so 'Check in to another branch' doesn't work unless we manually switch to allowing you to switch branches. Then once the files have been submitted to another branch you'd then have to switch back to your previous branch ready to carry on working on the other un-submitted files you have and switch the option back to don't allow changing branches with pending files.

Way back when I still used TortoiseSVN, I really enjoyed the fact that it's commit comment textbox would suggest types and filenames when committing new changes. See the attached image for an example.

The simplest implementation would be for the client to check the pending changes, compile a list of the filepaths and filenames, and then determine if the current typed word would match one of these list entries. If a word partially matches one of the entries, show a dropdown of these entries to let the user choose or dismiss the entries.

Just to elaborate, this is not an auto-fill feature (like #6389015), but more an autocomplete used to aid in comments like "VirtualFileBrowser now caches previous opened items" or "Removed Delete method from AbstractObjectCollection".

Now, the update triggers only provide a path to the workspace being updated.
Having access to the old and new changeset-id's opens up quite a lot new possibilities.

For example, in UE4, when working with plugins in a code project, they are compiled automatically at first. When making code changes to the plugins, they are often not automatically detected which causes the engine to crash at startup.
Deleting two specific folders makes the engine recompile those binaries automatically and thus fixes this inconvenience. Unfortunately, this process takes about 5 minutes on average so doing it after every update is not feasible.
By providing a specific string/tag in the comment of checkins that require a compile, we are able to only recompile when necessary.

In order to make this work, we have to write out the current changeset-id to a file in the before-update trigger. Then in the after update trigger, we get the current one. Finally we would use the find command to get all changesets in between those two and check if any of their comments contain the tag.

We are already able to access the current changeset-id with
cm status --nochanges
and some parsing. (Although this could be made easier.)
Thus, only exposing the future changeset-id in before-update and the previous changeset-id in after-update would suffice.

Thanks in advance

There is no context menu available for changed files in the 'Checking pending changes' window. However, there is a similar view in the 'Pending changes' tab of PlasticSCM's main window and a context menu is available there.

The thing is that the context menu enables you to view changes using a diff tool you prefer (the one set in application preferences). In the window mentioned in the topic there is no such menu at all and you can view changes only using the diff tool embedded inside that window.

Most of us in our company are used to WinMerge and we would like to continue using it with PlasticSCM. The 'Pending changes' view enables you to do that, but I think you rarely use it when managing source code changes directly from Visual Studio (which displays the discussed window).