Small new request, it would be nice if the Syn Replication view had the option to remotely create workspaces. I now have to use the commandline and retype a fairly long machine name (full AD one) to create a workspace at a remote machine.

So it would be nice (and easier with less chance on typing erres) if the Dialog for Add replication repository had the option to just select a server and add by typing just the repository name (or maybe even better have it already filled in with the local one, assuming names will probably match in a lot of cases).

To avoid mistakenly adding multiple xlink targets to the same source when creating sync views and to make sync view creation to repos with xlinks easier I suggest that the sync view editor should be "target" centric, not "source" centric:

I click add new sync view.
Instead of clicking add new source as I am supposed to now, I click "add new target".
I choose the target on a target server.
Plastic detects that I already have a repo with the same name on my source server (or use some other similarity measure as I have suggested above) and ask if I want to use that source repo, another source repo or create a new.
Plastic detects that the target repo has xlinks. For each xlink Plastic repeats the above check for a source repo and offers to use that, another or a create a new.

By using a target first approach, this would eliminate the risk of the above error and be very convenient.
Combine that with a button for syncing all targets and you have a near perfect sync view system.

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.

It happens from time to time that you think you are working on some branch when actually you are on another.

What I usually do in such a scenario is:
1. check in on wrong branch.
2. switch to correct branch.
3. cherry pick from wrong to correct branch.
4. copy the merged file(s)
5. delete new change set created on correct branch created by cherrypick.
6. copy the files back to the workspace (or just paste from clipboard if it was a single file).
7. check in the changes (now properly set in the correct branch).
8. delete the unwanted changeset that was created on the wrong branch.

If I could do the chery pick without leaving a link or if I could delete the link after performing the cherry-pick I could then just delete the miss-placed changeset and that's it.
Currently this is not possible because the existence of this link prevents me from deleting the changeset that was miss-placed in the wrong branch.