The new "multi-screen diff" in Plastic 6.0 is excellent. It was introduced in 6.0.16.884; if you have the Plastic SCM main window open on part of your screen, and open one diff window on another part of your screen, then the diff window's contents will change when you move around in the Branch Explorer.

(Slightly related uservoice: https://plasticscm.uservoice.com/forums/15467-general/suggestions/15615156-show-diffs-in-branch-explorer-and-changesets-views )

However, this has a few flaws related to cases where you don't want the "Diff changeset" window to change. To stop the Diff from updating when you click a changeset, you need more than one Diff window open. This is OK in theory, but in practice it works like this:

* If you double-click a changeset to open the 2nd Diff window, the double-click is ALSO interpreted as a single-click which updates the contents of the 1st Diff window.

* If you right-click a changeset to choose something in the context menu, this is ALSO interpreted as a single-click which updates the contents of the 1st Diff window.

* One of my coworkers is going nuts over this and would like an option to completely disable the auto-updating of Diff window content.

We need to be able to do a diff on a repository on a server (without workspaces) and then get the OLD version of a file through any xlink.

cm diff OLD NEW

You don’t get the path on the remote repository from a diff on current repository.

If I do a cm diff in the first repository, There is NO path information through the xlink. And ALL the information is related to the NEW changeset.

So you can not do a simple diff using the FIRST repository’s information:

$ cm ls '/one/two/My link with spaces/bird/file1.txt' --tree='24@00000000_99_TEST_REPO_3a@myhost:8087' --format="{revid}"

Can't resolve the selector for the item /one/two/My link with spaces/bird/file1.txt

Because all the info is for the FIRST repository, not the REMOTE repository xlinked to.

Doing a diff on the FIRST repository currently gives the following with NO information about the xlink:

$ cm diff '24@00000000_99_TEST_REPO_3a@myhost:8087' '26@00000000_99_TEST_REPO_3a@myhost:8087' --format='PATH:{path} STATUS:{status} TYPE:{type} PREVID:{parentrevid} REVID:{revid}'

PATH:"/one/two/My link with spaces" STATUS:C TYPE:X PREVID:-1 REVID:-1
PATH:"/one/two/My link with spaces/bird/file1.txt" STATUS:C TYPE:F PREVID:463 REVID:474

What is needed is the same NAME output variable as what ‘cm ls / -R’ provides, so you can get this using the diff command:
$ cm diff '24@00000000_99_TEST_REPO_3a@myhost.net:8087' '26@00000000_99_TEST_REPO_3a@myhost.net:8087' --format='PATH:{path} STATUS:{status} TYPE:{type} PREVID:{parentrevid} REVID:{revid} NAME:{name}'

PATH:"/one/two/My link with spaces" STATUS:C TYPE:X PREVID:-1 REVID:-1 NAME:My link with spaces -> xlink -> /dog/cat 42@00000000_99_TEST_REPO_2@myhost.net:8087

It would be nice if plastic had a web-service which provides graphical HTML5 reports / views for interagtion in thrid-party applications (primarily issue trackers)

I think of the following:
- Some branch-explorer like view focusing on one branch (task-branch) which displays the check-ins and merges to and from this branch
- A list of check-ins to a specific branch (like the history view?)
- A view showing all changed files in a branch in total
- you name it. there could be way more!

This service should have a REST-full URL API where the view and branch path are defined within the URL.

P.S. You started the web-interface some time ago and I hoped to see it develop in this direction. Sadly it didn't develop in any direction lately =/

Hi,

there is this user voice item:
https://plasticscm.uservoice.com/forums/15467-general/suggestions/4230341-add-ignored-files
which is about adding ignored files. We have the exact same situation from time to time.
The way to unignore the files leads to a crowded ignore list with lots of !xyz.dll entries. Although one could remove that entry once the item is versioned this is often forgotten and the ignore list is updated with the unignored item.
Another drawback is that people simply don't understand why they cannot add certain items. Especially when using the explorer context menu for adding items or folder structures there is no action at all. It just doesn't add it and if you haven't had this situation before you just don't get it why the operation failed (without any message).
I don't understand why the add operation is disabled for ignored items in the first place. Could you please allow adding of ignored item?
Thanks!
Jan

The "Cherry pick from changeset interval" is a bit confusing to me.

For example:
I want to cherry pick from changesets cs10 to cs15.
So, I intuitively select cs10 and cs15 and do a cherry pick interval merge. But then, I notice, that there is no cs10 involved. The merge begins at cs11 and not cs10.
So, when I want cs10 included, I have to select cs9. But that is very unintuitive to me.

It get's even worse, when I click on the merge arrow afterwards and it shows me "Changeset interval (9 - 15)".
That's wrong, because there is no changeset 9 integrated. It's cs10 to cs15 involved.

So, maybe, it's a philosophical problem about how you start counting or look at intervals. But for me, it's totally logical to select these changesets, which are also part of a merge. So, when I see "interval cs10 to cs15", I naturally think cs10 is involved and part of the merge. I would not think, that cs10 is only a boundary and not involved in that merge.

Could you fix this please or make it optional for the users, how the interval should be interpreted? (Maybe there are others around, who may have no problem with the current interpretation.)

In Branch Explorer, the alternating date-background color can be changed via a variable in a .conf file, but none of the other color schemes.

There is also the Themes feature in Preferences, but those seem to leave the Branch Explorer unaltered (even leaving it light for the dark themes)!

What we do have is the ability to color branches by attribute (conditional format) and to color changesets by user/replication-source. (But sadly, the color by replication source feature is currently broken.)

My request is to expose all the border, fill, background, selection and font colors to the user, either via .conf variables or via Themes customization.

These color settings would of course still be overridden by conditional format and changeset colors. Being able to change the default colors for borders, selection etc is important for readability. Also, for a consistent Theme look, we also need to be able to customize background colors etc.

Another (minor) issue is the darker border-color around the latest changeset on each branch, which I find to be only distracting (since the selected changeset is also using a dark border). So I would like to be able to choose the same border-color here as for other changeset borders.

Mostly, I'm interested in just making everything tweaked for visibility, so that it's easy to locate things. Too many different colors make it more difficult to get an overview. Every color should carry information. I like things like "color by user" but sometimes it gets in the way, if it makes it harder to locate the selected item for example...