531 results found

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

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Add a view and a command for viewing all xlinks in a repo

   I want to quickly list all the xlinks in a workspace, both in the GUI and on the command line.

   The "cm xlink" command lists info about one specified xlink, but how do I list them recursively (without doing a "cm ls -R | grep xlink" or using "cm fileinfo" in every subfolder)?

   I think there should be a command for this, perhaps "cm findxlinks", similar to "cm findprivate". A raw list of absolute paths to xlink-folders would do fine.

   Also, I would like a GUI view listing all the xlinks in a repo (similar to the Branches view).

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Improve the conditional format to support to coloring of branches with un-replicated change sets

   I want it to be possible to color branches that have change sets that have not been pushed to some other server via sync replication.

   To be specific and explain the background:
   I use jenkins to do some builds of my project when the main branch has been pushed to a central repository.
   it has happened to me several times that I checked in code (locally) and executed the jenkins project just to discover that it ran old code because my main was not replicated to the main server.

   I would be happy if my main branch would show with some color if it has change sets that have not been replicated to a specific replication server.
   (coloring all the other branches that have not been pushed is also o.k.)

   I want it to be possible to color branches that have change sets that have not been pushed to some other server via sync replication.

   To be specific and explain the background:
   I use jenkins to do some builds of my project when the main branch has been pushed to a central repository.
   it has happened to me several times that I checked in code (locally) and executed the jenkins project just to discover that it ran old code because my main was not replicated to the main server.

   I would be happy if my main branch would show with… more

   6 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Enable namespaced Labels, display as a tree view

   Just a simple (crazy?) idea. This would be very nice to have when the number of labels in a repo grows large. A hierarchical Labels view would be consistent with the rest of the Plastic UI.

   • Implement "soft" namespacing for labels (i.e "Namespaced Labels/Label 1"), similar to the one for branches.

   • Then add buttons "List view" and "Tree view" to the Labels view, just like the Branches view.

   Technical:
   No change is needed to how label names are stored, but the forward-slash character needs to be allowed in a Label name (it isn't currently, which is great since it means existing Labels won't be namespaced by mistake). The slash should be used to indicate namespace levels. You'd have to accept whitespaces in namespace names but that should not be a problem. Renaming by adding/removing slashes should modify the namespace of the label. Consecutive slashes should be left as-is but treated as a single slash. Namespaces containing only whitespace should be collapsed.

   (NOTE: backslash is currently allowed in a label name, which is a bit odd. If there is a problem with enabling forward-slashes in label names, backslash could be used but that would be less consistent with the rest of the UI.)

   Just a simple (crazy?) idea. This would be very nice to have when the number of labels in a repo grows large. A hierarchical Labels view would be consistent with the rest of the Plastic UI.

   • Implement "soft" namespacing for labels (i.e "Namespaced Labels/Label 1"), similar to the one for branches.

   • Then add buttons "List view" and "Tree view" to the Labels view, just like the Branches view.

   Technical:
   No change is needed to how label names are stored, but the forward-slash character needs to be allowed in a Label name (it isn't currently, which is great since it means… more

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Customizable columns

   Make possible to select visible columns in table views such as Changesets, Items, Branches, etc.
   We want to see Attributes and Labels in a Changesets view, but we usually do not care about GUIDs.

   142 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   4 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Enable re-merging

   A feature to enable the user to edit/re-merge a pending merge is something that would improve flexibility and greatly assist new users to the system.

   If you accidentally do something wrong in the merge, or change your mind and want to do something differently, it would be great to "redo" either file or the entire merge, and let you change e.g. from workspace to source contributor, or go over a merge of some code without having to undo. Now, after you've done a merge you reach a point of no return.

   1 vote

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   5 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. option to cancel workspace update

   A workspace update can be quite slow, particularly if you made a mistake in cloaked.conf. Rather than killing the process, it would be nice to be able to cancel the update.

   22 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Add "unrelated merge" indicator in 2D history and filtered branch explorer

   When viewing changeset history I tend to think about changesets in terms like "that is the checkin where I merged/rebased from /other_branch". That kind of context is sometimes lost in the Plastic views:

   • In 2D History if a merge is unrelated to the selected item then the merge arrow is not displayed.

   • In Branch Explorer if the /other_branch is hidden by filter, the merge arrow is not displayed.

   Not displaying the merge arrow in these cases is logical since the /other_branch is unrelated or hidden. However, I'd find it helpful to have some kind of (optional) visual indicator that an incoming merge is part of a changeset that is already displayed. (This should not affect the "Display only relevant changesets" option.)

   Perhaps you could render the incoming end of a merge-arrow and make it "fade away" or become "dotted" further away. Or display a special arrow icon to indicate the non-displayed merge. It would help bring the displayed changesets into context.

   Also, the "View history" and Changesets views could benefit as well from having different icons for each changeset line depending on whether there's an incoming (or outgoing?) merge etc. As it is, the icons in these list views are not really used to their full potential since they are all the same...

   When viewing changeset history I tend to think about changesets in terms like "that is the checkin where I merged/rebased from /other_branch". That kind of context is sometimes lost in the Plastic views:

   • In 2D History if a merge is unrelated to the selected item then the merge arrow is not displayed.

   • In Branch Explorer if the /other_branch is hidden by filter, the merge arrow is not displayed.

   Not displaying the merge arrow in these cases is logical since the /other_branch is unrelated or hidden. However, I'd find it helpful to have some kind of (optional) visual indicator that an… more

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   5 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. If a changeset is deleted, switch to the parent changeset and KEEP the changes in the "pending changes"

   When a changeset is removed the workspace is switching to the parent changeset and all changes get lost.
   I think it is better to keep all changes in the "pending changes", so you do not lose any changes and you can add some more changes.

   It often happens to me that I forget some small changes, so I have to check in again producing a lot of unnecessary changesets.

   87 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   12 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Add default filter in Changeset Diff opened from (2D) History

    This suggestion is a simple and minimal solution to a feature that is missing in Plastic and that we used a lot in TortoiseSVN - the ability to filter a Changeset Diff to the subtree-path that we're viewing the History of.

    I have earlier suggested more elaborate changes to support this feature, but the simplest possible fix for this is as follows:

    When opening a Changeset Diff from a (2D) History view of a directory (subtree), automatically populate the "Filter:" box (for the Changeset Diff) with the workspace path of the directory that the History view is working against. (This should be done even for "Diff selected changesets".) That way we will see only the items located in the relevant subtree.

    (For symmetry/simplicity, this could be done for the History of a single file as well. That is not necessary though, since it would show the same changes as the inline Diff.)

    For this to be a flexible solution, there should also be added a checkbox next to the "Filter:" box so we can toggle the filter on/off. (That would be a good feature to have, even on its own...)

    The value of this checkbox can be saved to a .conf file. To avoid a change in the default behavior, you can let this checkbox be unchecked initially. Also, when the user manually changes the filter string, you can let this checkbox become checked automatically.

    It would be really super to have this simple auto-populated and toggleable filter, since we often want to review the history of changes done in only a sub-tree!

    NOTE: In TortoiseSVN this feature is activated by the checkbox "Show only affected paths" in the "SVN Show Log" dialog.

    This suggestion is a simple and minimal solution to a feature that is missing in Plastic and that we used a lot in TortoiseSVN - the ability to filter a Changeset Diff to the subtree-path that we're viewing the History of.

    I have earlier suggested more elaborate changes to support this feature, but the simplest possible fix for this is as follows:

    When opening a Changeset Diff from a (2D) History view of a directory (subtree), automatically populate the "Filter:" box (for the Changeset Diff) with the workspace path of the directory that the History view is working against. (This… more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Display more information in the Repositories view

    In the Repositories view, very little information is displayed about the repositories listed: Name, namespace/hierarchy, server. That's all.

    When I list my repositories I want to see something similar to the Branches view: Owner, Creation date, Comment

    (The Comment field was requested in another uservoice: https://plasticscm.uservoice.com/forums/15467-general/suggestions/8063376-repository-description)

    But most importantly, I'd like to see number of branches, number of labels, number of changesets! This info could be displayed in an "extended information" sidebar, also just like in the Branches view.

    4 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    5 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Search in Branch Explorer should include Branch Comments

    The filter box in the Branches view gets hits on words in the branch comments, but the Search box in Branch Explorer does not.

    6 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Extend "Explore changesets on branch" to new command "Explore history" in Items view

    When looking at a branch, we find the "Explore changesets on this branch" window to be very useful, more so than the similar "View changesets on this branch".

    In the Items view, the command "View history" is similar to "View changesets on this branch" but it is further filtered to cover only the selected subtree or single file. However, there is no equivalent to the "Explore changesets on this branch" window for the Items view.

    I propose adding a context command "Explore history" in the Items view, so that the excellent "Explore" window can be similarly filtered to a subtree or file.

    When looking at a branch, we find the "Explore changesets on this branch" window to be very useful, more so than the similar "View changesets on this branch".

    In the Items view, the command "View history" is similar to "View changesets on this branch" but it is further filtered to cover only the selected subtree or single file. However, there is no equivalent to the "Explore changesets on this branch" window for the Items view.

    I propose adding a context command "Explore history" in the Items view, so that the excellent "Explore" window can be similarly filtered to a subtree… more

    4 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    8 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Possibility to merge independently added files/directories

    Two folders (or files) with the same name added into different branches independently, cannot be merged in Plastic now.
    It would be priceless in some cases (especially for folders).
    http://www.plasticscm.net/index.php?/topic/1224-evil-twin-conflict-resolution/
    http://www.plasticscm.net/index.php?/topic/391-directory-merge-fail/

    175 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    20 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Lock a Branch

    LOCK a branch so no one can perform a merge or checkin except the one who took the lock.

    Current scenario: Two or more developers are are working on child branches and want to merge back to the parent branch, if both initiate the merge, the first will succeed but the second will have to re-merge again. To avoid this, the developers can send an email, asking all to wait until he finishes the merge...
    Proposed solution: Allow the one to take a lock on the target branch, do the work, and release it. During the lock, others should be restricted from accessing or doing actions on the lock (including an attempt to merge).

    LOCK a branch so no one can perform a merge or checkin except the one who took the lock.

    Current scenario: Two or more developers are are working on child branches and want to merge back to the parent branch, if both initiate the merge, the first will succeed but the second will have to re-merge again. To avoid this, the developers can send an email, asking all to wait until he finishes the merge...
    Proposed solution: Allow the one to take a lock on the target branch, do the work, and release it. During the lock, others should be… more

    102 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    4 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Show current changeset in "selector bar" (below workspace tab)

    When starting the Plastic GUI (on Windows), the tab for the active workspace tab is selected. Below that is a "selector bar" indicating what's currently loaded (switched to) in this workspace.

    If the workspace is switched to a Branch/Label, there is no immediate way to find out which changeset number is actually loaded right now.

    Example: When switched to a branch, if the workspace has not been Updated recently we may not be at the latest changeset on that branch.

    I propose displaying the actually loaded changeset number in this "selector bar", to have this crucial information readily available regardless of view!

    (If switched to a Changeset, this means the same number will be displayed twice but that should not be a problem as long as it's obvious which number is from the selector and which is the actually loaded one. Alternatively, the actually loaded number could be omitted in this case.)

    When starting the Plastic GUI (on Windows), the tab for the active workspace tab is selected. Below that is a "selector bar" indicating what's currently loaded (switched to) in this workspace.

    If the workspace is switched to a Branch/Label, there is no immediate way to find out which changeset number is actually loaded right now.

    Example: When switched to a branch, if the workspace has not been Updated recently we may not be at the latest changeset on that branch.

    I propose displaying the actually loaded changeset number in this "selector bar", to have this crucial information readily available regardless… more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    3 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. conditional format/in-/exclusion rules based on repository

    Right now I have no way to define custom rules for only one repository.
    Also it is not possible to identify the repository within the rules condition.

    Workaround: add a attribute to each branch containing the repository name. (Very very nasty)

    It would be nice to:
    1) have a repostoryName variable within conditions
    2) have custom rules for only one repository

    9 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. MergeTo operation shall support --mergetype and -c/-commentsfile

    It looks that currently MergeTo operation is ignoring --mergetype parameter. If only automatic merge of changes from both source and destination is possible Plastic is doing it.

    It would be good to have a chance to explicitly show that changes only on one side are allowed and exit with failure if there are some also at the other.

    Additionaly for now it is not possible to give comment which will be used for check-in operation after successful mergeTo.

    6 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    3 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    planned  ·  AdminCodice Software (CEO / Founder, plasticscm) responded

    On the release 7.0.16.2077, we added the new server-side merge that extends the existing merge-to functionality.

    Using the server-side merge, the file conflicts can be resolved and the merge resolution options (—mergetype, —keepsource & —keepdestination) are supported.

    The server-side merge is still on preview so you need to enable it adding the following setting on the client.conf. Check how to do it on the release notes: https://www.plasticscm.com/download/releasenotes/7.0.16.2077

    Remarks, the server and client version must be equal or newer than 7.0.16.2077 to use the server-side merge.

    We comment option will be documented soon, we already plan a task to do it in the next few weeks. Sorry for the delay.

    Best regards

    Borja

19. Make Diff listen to file-change-notifications and ask to reload

    The Diff view/window in Plastic does not listen to filesystem notifications about file-changes when diffing a file in a workspace.

    It should discover external changes to the workspace file and ask to reload/recalculate the diff when needed. Other Diff tools I have tried do this...

    6 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    3 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Show Home changeset whenever possible

    I would like the "Home" changeset to always be shown (when at all possible) in all the branch-explorer/2D-revtree views. This would make it easier to relate the view to the current workspace contents.

    In all those views, I'd like the Home changeset to be displayed regardless of date filter (possibly with a dotted parent-changeset arrow to connect it with the nearest date-filter-included changeset).

    In the 2D revtree I simply want an extra U = Unchanged changeset (on the relevant branch) with the Home icon above it, in the cases where the home changeset/branch would not otherwise be included.

    NOTE: Exclusion filters and visibility mode etc should still be applied to the Home branch...

    I would like the "Home" changeset to always be shown (when at all possible) in all the branch-explorer/2D-revtree views. This would make it easier to relate the view to the current workspace contents.

    In all those views, I'd like the Home changeset to be displayed regardless of date filter (possibly with a dotted parent-changeset arrow to connect it with the nearest date-filter-included changeset).

    In the 2D revtree I simply want an extra U = Unchanged changeset (on the relevant branch) with the Home icon above it, in the cases where the home changeset/branch would not otherwise be included.

    NOTE: Exclusion… more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close