526 results found
-
Show the current branch in Workspaces overview
Currently, in the Workspaces overview, you only have columns for "Name", "Path" and "Repository". It would be nice to have another column "Current Branch".
This would make it easier to identify the correct workspace for a certain branch when having multiple workspaces with varying branches.
7 votes -
Improve semantic outline to launch difference child window
Right now the semantic outline only allows you to navigate to a difference, and selects it in the diff view.
If I want to launch a separate window to view the differences I have to go to the diff window and click on the little "C" icon to pop up a view of the difference.
I would like to be able to launch this directly from the outline by double-clicking, Ctrl+Click, or right-click -> context menu.
This should be a simple improvement but will make using the semantic outline much more natural
3 votes -
Allow CM Find to work on all repositories without needing to specify each repository
Currently you have to specify each repository you that you want cm find to look at. Unfortunately if you have a lot of repositories this takes a lot of typing (we have 100+). It would be nice if you could use an identifier to tell cm find to look at all repositories. For example: cm find changesets where owner='sbaum' on repositories '*'
3 votes -
Add more tab-sizes in Diff / Merge Editor Options
Here's a quick one:
In Diff / Merge view, the "Options - Editor Options - Tabs" submenu contains only 2 options: "4 spaces" and "8 spaces".At work, we consistently use 2 spaces. Therefore, please add a third option: "2 spaces". Or simply add all the possible choices from 1-10 or such...
3 votes -
Partial file checkin
Would you consider adding an option to check in only selected changes in a file? I once saw such option in SourceTree. At first I thought it was useless, but sometimes I actually need to check a file in without certain changes made in it.
I think you could add the feature to the diff viewer in Pending Changes. Each modified line could have a check box next to it, checked by default. What do you think?
23 votes -
The "All repositories" tab should open as a top-level view/route
Currently when you try to access the list of all repositories, it opens beneath the current workspace tab. Then when you choose "View branch explorer" on a project, it opens another sub-workspace tab so now my workspace has two branch explorer tabs open in it, and one of them is not even related to the workspace. Clearly this is not the right place for these tabs to open. The Mac client does better by opening the repository list and workspaces in new windows. I'm sure you can come up with a better placement in the Windows client- for example, open…
1 vote -
Add an option to prevent changing branches when you have added (private) files which are marked as pending adds.
This would prevent you from adding a file and forgetting to add it to source control before changing branch. This idea here is that you would set Plastic up to discover private files so you can see which files need adding. Any solution files or built data you would put in separate folders which aren't under source control and thus aren't detected by Plastic. This approach prevents you from forgetting to add files, i.e it'll build for you locally but not for others.
12 votes -
Allow update-merge on "Update Workspace" and "Switch"
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…12 votes -
Track the evolution of a section of code back through revisions
This overlaps with the existing version tree functionality in Plastic, and with the existing annotations functionality - and is probably related to method history too.
My use cases are:-
I see a piece of code that is broken, but don't know anything about what that code did in the first place, when it was introduced or who did it, and what were the checkin comments.
Again, I see a piece of code that is broken, and I want to jump straight to the diff for that piece of code in whatever revision introduced the breakage. If that revision turns out…
6 votes -
Add the ability to tag repositories
Similar to the request to group workspaces and repositories (https://plasticscm.uservoice.com/forums/15467-general/suggestions/2772036-group-workspaces-and-repositories) but not quite the same.
Using submodules to group repos limits you to a single classification of a repository. Ideally you are able to tag a repository with several keywords like you do on a forum or an article. This would allow us to tag a repository with 'real-time control' or 'imaging algorithm' but also tag it with a product name that uses it or the programming language that it is written in.
This would necessitate a new repository view in the client where instead of a list…10 votes -
Configurable Read-Only access for GitServer
Currently GitServer feature does not allow to configure any security.
It would be nice to have at least possibility to limit access from GIT to read-only via configuration.1 vote -
Add option "Ignore blank lines" (like "Ignore EOLs") as comparison method
I often have more or less blank lines after debugging. When I do not like them to checked in I have to go through all changed files and add / remove blank lines. It would also be great if the menu items have a checkbox, one per option (Ignore EOLs, Ignore whitespace, Ignore blank lines).
4 votes -
layout branches in branch explorer by attribute
I use the manual relayout mode to layout my branches in a way, that release branches are on top, the trunk is in the middle and all issue branches are below.
This way I have a fast overview of the changes that are released.
[They also have different colors ;)]All these branches have an attribute called "role" with different values:
"Release" for releases
"Trunk" for the trunk
"Patch" for issuesNow, it would be VERY nice if I could teach the branch explorer, that branches should be layed out in an order (top to bottom) based on the attribute…
6 votes -
Gluon, compare contents of text files instead of time stamps
Gluon, compare contents of text files instead of time stamps.
Text files that are exactly the same are being seen as changed in Gluon.
1 vote -
Indicate whether or not a changeset / branch has been synced from the Branch Explorer
Do something (change color, icon, etc) to show that changesets/branches have not been synced.
6 votes -
Add option to always show active branch
When using inclusion/exclusion filter-rules in Branch Explorer, the active branch may become hidden. I want some way to force the active branch to be always visible.
There is a special coloring-rule (currentselectorbranch) for the "Active branch in this workspace", but there is no way to do the same in an inclusion rule. (As I don't think it's possible to locate the active branch via a simple find-branch-query?)
I propose adding a way to (optionally) always show the active branch. This could implemented simply as a new "Display option" - "Always show active branch" or as a special inclusion…
3 votes -
Having the ability to set an Icon for each repository
If we could set individiual icons for each repository (like its possible in Jira) working with many repositories becomes more easy. Currently I have to ensure that I am looking at the correct one by looking at the name. Just quickly checking the icon would be a lot faster.
Additionally the names do not fit into the workspace tabs, having a small version of the icon displayed there would switching workspaces much quicker.3 votes -
Optionally affect xlinked repos when doing "Apply label to workspace contents"
When applying a new label, there is a checkbox "Label all XLinked repositories".
However, when moving a label ("Apply label to workspace contents") there is currently no way to automatically apply (or move if existing) a label by the same name in xlinked repositories.
It would be very nice to be able to do this (as an option).
3 votes -
Add prio order for inclusion and exclusion rules as well
In Branch Explorer, it's hard to combine inclusion and exclusion rules since there is no way to adjust priority order between them, and exclusion always seems to override inclusion.
I would suggest evaluating (for each branch) the inc/exc rules from top to bottom and stopping at the first (enabled) matching rule (just as for the custom coloring rules). Then you could re-use the "move up" button for adjusting these prios (only keeping the separation of color-rules from the inc/exc rules).
3 votes -
add branch alias
Would be cool to have aliases for branches.
The whole system builds up on branches names and you may refer to them from other programs, so you can't change the name.Example: Branch with name 'Task0815' is a new feature called 'Branch aliases' (see what I did there? ;])
In the Branch Explorer this branch could be displayed as:
Task0815 | Branch aliasesThis would enhance the overview inside the branch explorer, because having Task001 to Task999 isn't telling you much.
At the moment this would be inside an attribute or the branch description, but both aren't displayed until you…
3 votes
- Don't see your idea?