I'd like the ability to delete branches. If the changes have been merged into another branches, keep them. Otherwise produce a STRONG warning that changes will be lost forever.

Use cases:

(1) Lots of branches on the server. When I sync some locally, I'd like to clean them up to remain organized.
(2) Abandoned branches and code that we no longer want. We'd like to prune them to keep our repo organized and focused.

I fully understand that "deleting branches is not recommended".. however, that is a recommendation, not a rule. I should be able to accept the responsibility of deleting branches within the practices of my organization, even if Plastic SCM (the company) does not agree.

I'd like the ability to delete branches. If the changes have been merged into another branches, keep them. Otherwise produce a STRONG warning that changes will be lost forever.

Use cases:

(1) Lots of branches on the server. When I sync some locally, I'd like to clean them up to remain organized.
(2) Abandoned branches and code that we no longer want. We'd like to prune them to keep our repo organized and focused.

I fully understand that "deleting branches is not recommended".. however, that is a recommendation, not a rule. I should be able to accept the responsibility of…

When viewing the list of code reviews on the code review screen it would be great to have some indication that comments have been added to a review without having to open the review.

An extra column with an icon would work pretty well but also if each review in the list could be clicked on to expand showing a nested grid with a preview of the first 3 comments that would be helpful too...

Occasionally I forget to refresh the pending changes view before a Checkin. This is annoying as immediately after the checkin operation then view automatically refreshes, sometimes revealing changes that missed the checkin!

Preparation:
Create a new branch based on a specific changeset of an existing branch.
Lets assume the new branch is called 'test', the existing branch is called 'parent' and the changeset on branch 'parent' is 1234.

There currently is no cm command to find that changeset number (1234) when the branch 'test' itself has no changesets.

cm find changesets where branch='test' will have 0 total changesets

cm find changesets where branch='parent' will have all changesets of parent, but you don't know which is the base line for branch 'test'

If you launch the Plastic installer when an application is running which needs to be closed, you are presented with a list of the applications which need to be closed, and three buttons:
Refresh List - Continue - Cancel
... where Continue is grayed out ...

In order to proceed from that point onward, the user needs to first close the applications, then click on Refresh List, then click on Continue.

You could simplify this by combining the "Refresh List" and "Continue" operations into a single "Refresh" operation:

Remove the "Refresh List" button. Replace the "Continue" button with a "Refresh" button.

This "Refresh" button will refresh the list of apps that need to be closed, and - if the list is empty - automatically proceeds to the next stage in the installer.

If you launch the Plastic installer when an application is running which needs to be closed, you are presented with a list of the applications which need to be closed, and three buttons:
Refresh List - Continue - Cancel
... where Continue is grayed out ...

In order to proceed from that point onward, the user needs to first close the applications, then click on Refresh List, then click on Continue.

You could simplify this by combining the "Refresh List" and "Continue" operations into a single "Refresh" operation:

Remove the "Refresh List" button. Replace the "Continue" button with a "Refresh"…

This is a minor thing but one that bugs me a lot. In P4, when you have multiple files selected in the pending changes view, you have hit ctrl-d to diff all the selected files against the current revision. Plastic has the same feature except it only functions when you have a single file selected.

I find it very usefull to trigger a diff for multiple changed files so that I can review all changes without having to constantly context switch back to plastic to open the next file. Alternatively I have to manually select each file, hit ctrl-d, which for a largish changelist can take a while.

This is a minor thing but one that bugs me a lot. In P4, when you have multiple files selected in the pending changes view, you have hit ctrl-d to diff all the selected files against the current revision. Plastic has the same feature except it only functions when you have a single file selected.

I find it very usefull to trigger a diff for multiple changed files so that I can review all changes without having to constantly context switch back to plastic to open the next file. Alternatively I have to manually select each file, hit ctrl-d, which…

When I browse through the Commit History and select a .cs file, then select Semantic diff, and then switch the commit, then depending on the file type that is selected gmaster falls back to Text diff. This is correct behavior I guess, but when I switch to the next commit and it is a .cs file again I would have expected that I get the Semantic diff again, but instead I am in text diff mode and have to switch manually.

In the absence of a "Sync All View" in Sync Replication View, have a visual marker to indicate out of data repos so it can be determined at a glance which repos are out of sync and require syncing. Probably a different colour for repos with incoming changes and a different colour for outgoing changes, and something to indicate there are both incoming and outgoing.

When I'm managing several changelists I give them different names depending on the context. When checking in, I'd like to have the option of using the changelist name as the comment, instead of typing in the comment first and then choosing to check in the changelist.

I'd like to check in "Feature XYZ" but not "Spelling error" (as it might be irrelevant to the feature changelist). I would like to:

1. Right click on "Feature XYZ" and select "Checkin Changelist"
2. A dialog box pops up with the comment field, prepopulated with "Feature XYZ" as the changelist comment.
3. I alter the comment "Feature XYZ" if I want, or otherwise just click on "Checkin" button on the new dialog and check in.

.. something like that. Having to enter something into the "main" comment box each time is cumbersome.

Thanks!

When I'm managing several changelists I give them different names depending on the context. When checking in, I'd like to have the option of using the changelist name as the comment, instead of typing in the comment first and then choosing to check in the changelist.

In SVN there was a great feature that allowed you to select multiple files in your "Local Changed" window and the press "Show unified diff".
This would compare all the files and show you all the changes in one window.
It would give you information inbetween the changes to let you know which file you were viewing the changes at.

This was great when you did a "rename" on a variable on hundreds of files etc. Allowing for quicker code reviews ( that are important at our company ).

Currently local changes to comments and or labels do not register as changes, and thus are unable to be synced outside of the initial commenting or labeling.

There have been many times I required a developer to add more details to their initial comments, and or had to fix a bad label, and had to change it in multiple places rather than in just one followed by telling everyone to sync.

I feel this is a very worth while feature to include; as that meta-data is what effectively describes a change-set and right now any changes to those items requires a lot of manual replication to update everyone's local repositories to match.

Currently local changes to comments and or labels do not register as changes, and thus are unable to be synced outside of the initial commenting or labeling.

There have been many times I required a developer to add more details to their initial comments, and or had to fix a bad label, and had to change it in multiple places rather than in just one followed by telling everyone to sync.

I feel this is a very worth while feature to include; as that meta-data is what effectively describes a change-set and right now any changes to those items requires…

Applying resolution to structural conflicts in the merge panel prior to "Process all merges" takes a long time, in the region of 10s per element. I don't see any technical reason for this to be so damn slow - please see if you can fix that. Often you have to redo a merge after something went wrong and every time you need to wait like forever in that step.

RIght now, `!/foo` and `!/foo/**` do exactly the same thing. It would give developers an extra degree of control if `!/foo` alone, or `!/foo/`, caused the directory entry foo to be unignored without unignoring its contents.

If you ignore a directory tree, unignore a file within that tree, Plastic will allow you to add and checkin the unignored file, but not any of the folders in-between it and the root of the ignored tree. This results in the file not being downloaded/checked-out by others.

In a DevOps environment developers want to have automated tests run on each checkin.
To trigger the test runs we can use after-checkin triggers, that's great!
Developers will then get feedback on the changes they made.
This is via mail right now.
But the test results will be needed by other developers, too.
So the results should be placed inside plastic scm connected to the changeset.
This is a additional (optional) request: It would be nice if it was possible to add test reports in HTML format to each changeset and to be able to view them inside plastic scm.

But what I really wanted with this user voice:
It should be easy to see whether a changeset has been successfull tested.
So my idea is:
I add a custom attribute to each changeset containing the test result.

I would then need a way to change the appearance of the changeset bubble inside the branch explorer based on the attributes value.
So for example:
a passed test run will be a round bubble
while a failed test run should be a triangle shape
and a pending test run is a diamond shape

this could also work with broder colors.
with red, green and yellow borders.

because the changeset background color is used to visualize the synchronization source, this property is not an option.

Think about it ;)
This will make plastic even more awesome!!

In a DevOps environment developers want to have automated tests run on each checkin.
To trigger the test runs we can use after-checkin triggers, that's great!
Developers will then get feedback on the changes they made.
This is via mail right now.
But the test results will be needed by other developers, too.
So the results should be placed inside plastic scm connected to the changeset.
This is a additional (optional) request: It would be nice if it was possible to add test reports in HTML format to each changeset and to be able to view them inside plastic scm.