Skip to content

General

General

Categories

JUMP TO ANOTHER FORUM

526 results found

  1. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. 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:-

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

    2. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. 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 issues

    Now, 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. Do something (change color, icon, etc) to show that changesets/branches have not been synced.

    6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. 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 aliases

    This 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  • Don't see your idea?