535 results found
-
Add "Update Cloaked" (and "Update Forced") to Items context menu.
If i have items or xlinks specified in cloaked.conf, the only way to force an update of these is to:
either removed them from cloaked.conf before "Update workspace"
or run "cm update --cloaked <path>" from the command line.
NOTE: Contrary to old documentation, running the "cm update --forced <path>" command will not update cloaked stuff.
I suggest adding a "Update Cloaked" command to the context menu in the Items view. Maybe also an "Update Forced" command, but this is probably less important.
17 votes -
Code review per Branch compared with another Branch
Currently Plastic allows Code Review Per Branch. Problem is it shows differences between the original node from which the feature branch was created (in dev) and the head node of the feature branch.
However, this is a problem: when you update your feature branch merging updates other devs have merged in dev branch.
Why? Because all their changes also appear in the code review. So at this point is not possible to do a reasonable code review of the code in the feature branch.
The solution: Take the same approach that BitBucket takes. The code review should show only differences…36 votes -
make the download link for "you need dokan.dll" clickable
When I choose "Mount this changeset in Plastic Drive", I get a long and confusing text message because I do not yet have dokan.dll installed. The text message contains a long URL with the download location.
Even if you are not going to make the installation process automatic, you could still reduce friction by making the download URL clickable. This makes the URL stand out from the rest of the text, and makes 'the right choice' easier.
3 votes -
use the .gitignore file if it is present
Have plastic simply use the .gitignore file if it is present. Now that we support the online git repos like github bitbucket and VSO.
If you have .gitignore use that methodology and if you have .ignore use that methodology.
And maybe give user option to generate a .ignore file from a .gitignore.
21 votes -
Repository description
Add a description property to a repository and add it as a column to the repository browser to allow for a long description to give detailed information about the contents of the repo. Repo names tend to be short and don't always explain what the repo contains, especially when there are 100's of repo's for different projects.
15 votes -
Indicate out of data repos in Sync Replication view
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.
1 vote -
Possibility to split changesets
Problem:
Sometimes you checkin changes that aren't necessarily corelated. Well, yes they belong to the same fix, but you could easily revert one change without the other.
When people don't have the habbit to checkin every now and then, they need to checkin when they're done. Most of the time, this checkin contains more than one change.In the unexpected event of a new bug, that was checkedin with these changes, it's hard to revert that one change that's causing the issue.
Suggested solution:
This problem could be solved if there was a way to split existing changesets into new…9 votes -
Ignore Case in Diff View
Some languages, like Visual Basic 6, are case insensitive. An option to ignore case sensitivity would remove some of the false positives the Diff Viewer reports because of case differences.
7 votes -
Visual Studio plugin: Jump to current line when opening Annotate
When opening Annotate from the code editor in Visual Studio, pre-select the annotated line that corresponds to the cursor position in the code editor (and scroll it into view).
7 votes -
Simplify installer's "Close Processes" UI
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"…
3 votes -
Improve usability of the embedded code review system
The code review system is very basic but I believe a few simple things can make it much more usable. I submit a list of them here: http://www.plasticscm.net/index.php?/topic/2276-suggestions-for-code-review-system
59 votes -
gmaster switches to Text diff on unsupported file, but does not switch back to Semantic diff
Fist of all, thank you for this great tool!
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.
3 votes -
teamcity plugin - support Branch Remote Run Trigger
https://confluence.jetbrains.com/display/TCD10/Branch+Remote+Run+Trigger
allows personal builds to get triggered off specified branch spec.
3 votes -
Commenting xlink changes in code review
"Xlink changes cannot be commented" - that message shows up when you try to comment a change in an xlinked file (in a code review). IMHO it would be much easier if xlinked files could be commented just like other files.
122 votes -
Mine vs theirs branch names
Keep Mine vs Keep Theirs... as the guy doing the reviews it would be nice if I could see the branch names for "mine" and "theirs"
5 votes -
rules for changeset appearance based on attributes (DevOps test results)
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.…
3 votes -
create shelve from changeset
You should add a way to shelve a already checked-in changeset. This way a checkin on the wrong branch could be shelved, deleted and then applied to the correct branch.
33 votes -
Better compare for different image size
If I can compare image with different size, then is it imposible
1 vote -
Allow the pending changes view to ignore EOLs
(see http://www.plasticscm.net/index.php?/topic/2883-pending-changes-does-not-ignore-eols/)
I would like an option to allow the Pending Changes view to ignore EOLs.
Ideally this would happen automatically, so that if the option were enabled differences which are simply down to EOLs are not treated as pending changes.
Another idea
4 votes -
To have the possibility of add general comments per code review and per file in the code review
I would like to don't be forced to always attach a comment to a concrete line. I want to have the possibility of adding general comments to the review and to files in the review
12 votes
- Don't see your idea?