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

When working in the Visual Studio plugin, changed files are always Checked-out when saved. If you re-save a file after restoring it to original contents (by Ctrl+Z or tweak-untweak a value etc), it's still Checked-out and will still appear in Pending Changes with a "Files are identical" Diff. The preference "Compare file contents instead of timestamps when determining Changed status" does not help here as the file is explicitly checked out.

There is an "Undo unchanged" command but it's dangerously close to the "Undo changes" button. It would be nice to have the option to always perform a silent "Undo unchanged" whenever refreshing the Pending Changes view.

Here are a few ideas for an improved issue tracker API. These suggestions were first posted in the forum 05 December 2011.

Create branch from ticket
I was surprised that I could not create a branch from a list of tickets. Instead I have to use a branch name convension to link my branch to a ticket. It should be trivial to extend the extension API with a "load tickets" method and present the list of tickets when creating a branch. How to select the tickets to be shown could be a matter of extension configuration. This could be made even better if the API could make the extension provide a list of filters to choose from.

It is not that it is a big issue to use the branch naming convension, but it would allow a more smooth workflow if the list of tickets was integrated with branch creation.

Two way state synchronization
I was also surprised that the extension seems to be a one way system with no support for adding states or comments to the ticketing system.
I had expected to find a "hook" to branch switching or creation. That way it would have been possible to change ticket state from say "new" to "open".
If the ticket properties, especially state, were synchronized with Plastic attributes, it would provide a very convenient way of filtering branches when integrating completed tasks for a build.
If there was a "hook" for changeset comments, changeset comments could also be added to the ticket comments. This would provide possibilities for a detailed change log.
Two way states and events on commits, branch switches, etc. is what I miss the most.

Caching
I would benefit performance if every branch explorer refresh didn't caused a complete loading of all issue tracker tasks in view. You might expect the branch explorer to attempt a refresh if you hit the refresh button, but it the refresh fails, for example if you are offline or the ticket server for some reason is not available, then all your ticket titles disappear. This is a problem if you have adopted a ticket id branch naming scheme. It would be better, if Plastic cached tickets and only replaced titles if a new was actually loaded. Also, why is the extension asked to load a ticket both by the branch explorer and when clicking on a branch?
I do however realize that the extension could do such caching by itself, but it would be easier to develop extensions if such behavior was implemented in the calling system.

Repository mapping
I found the repository to ticket system project mapping a little clumpsy in the API. E.g. when refreshing the branch explorer, the extension is asked to load tickets for all visible branches, but with the empty string as repository name. Only when clicking on a branch, the repository name is provided. There is probably an explanation, but it made it hard to map repositories with projects in the ticketing system. This is a problem for ticketing systems like YouTrack, where the project name (in short form) is part of the ticket ID and IDs within projects are sequential (i.e. non-unique globally).

Auto comments
In Plastic preferences you can setup auto-comments. You can choose between user name and date. This is almost entirely useless since that information is already baked easily available.
When using build servers like TeamCity, you get some nice links to your ticketing system if you refer to ticket id's in the comments. A typical workflow is making a solving a bunch of tickets and then integrating the branches in a build branch that the build server will use to generate a new build. In the process of integrating branches, it would be helpful if the comments automatically the ticket ids, since this would make a full circle between the VCS, Build server and ticketing system. Manully entering these comments is tidious and error prone, since it is often only a matter of repeating branch names and ticket titles.
It would be nice if the "custom" auto-comment formatter was extended more tags. Most obvious are branch name, ticket title, ticket id, ticket description.

Back in old Subversion, the scenario of "Updating to a newer changeset (on the current branch) while there are Pending Changes in the workspace" was handled very smoothly and seldom caused any problems. (Sure, conflicts can arise but they are usually minor since we are on the same branch.)

I'm aware that it's recommended that each developer works on their own child branch. Nevertheless, this situation comes up, for example when two child branches are being concurrently merged back to the parent. Also, the Plastic team has already put some work into supporting this scenario:
http://codicesoftware.blogspot.com/2012/02/working-on-single-branch-update-merge.html
"While our recommended pattern is definitely branch-per-task, sometimes you’ll find yourself sharing a branch with another developer or even the whole team."

Unfortunately, the current handling of this scenario is not optimal. There are (at least) 3 methods for updating the workspace to the latest contents on the current branch, and the third method differs from the first two in ways that are hard to predict:

(1) Pressing "Update workspace" button on the Items view.
(2) Switching to the same branch.
(3) Pressing the "View new changes" button that appears in the Pending changes view when there are newer changesets.

The setting "Other Options - Behavior when trying to switch / update with changed items" / PendingChangesOnSwitchAction controls some aspects regarding the behavior of method (1) and (2). When using the "No-Checkout" workflow, it has been recommended to choose the option "Allow" or "Allow, showing a warning" for this setting. However, in my experience this does not work well at all. This setting only affects Changed files and it causes several problems, even potentially blocking a subsequent Checkin! On the other hand, the default option "Do not allow, show an error" will prevent any attempt to use method (1) and (2) when there are local changes. Also, if there is any checked-out items, method (1) and (2) will be disallowed regardless of settings.

(Details: If I switch/update with locally Changed files with the above option "Allow, showing a warning", I get the Confirm Update dialog. If I then choose to continue with the Update, I get the Update Results dialog. Here, my Changed files are listed as "not up-to-date" even if the new changesets on my branch contained only changes unrelated to these files! And if the new changesets on my branch _did_ contain changes related to my changed files, I may even become unable to Checkin because of an error "parent revision is inconsistent with the loaded one"! Also, if I use "Update forced" I would lose my local changes.)

Method (3) is only available if we have activated "Look for newer changes in the repository" under Options in the Pending Changes view. This method is working much better, since incoming changes are handled by a sub-branch-merge.

(NOTE: When cloaking is active, the method (3) will always cause a Merge instead of an Update if there are newer changesets, potentially leading to unnecessary "sub-branching" even when there are _no_ changes in the workspace!)

My suggestion is to:

* Completely remove the setting "Behavior when trying to switch / update with changed items"
* Handle "Switch" and "Update Workspace" (method 1 and 2) very similar to "View new changes" (method 3).

This would make the handling much more consistent. Both Changed and Checked-out items can then be merged, and a trivial switch/update can be performed if there are no conflicting files.