The "cm patch" command is able to yield diffs in the standardized "unified diff" or "unix patch" format as console output. However, there is no simple way to yield the same kind of console output for the Pending Changes.

Our Linux users are demanding this, and they are surprised that it is not currently possible since they are used to this behavior from "cvs diff", "svn diff", "hg diff" and "git diff".

We suggest adding this functionality to the "cm patch" command. All that's needed is to output the same kind of "unified diff" as usual, but based on the diff of the current pending changes in a workspace. Either by adding another option flag to the "cm patch" command, or by simply calling it without arguments.

When adding a new xlink to a project, you must select a target changeset to track on the linked repository. When you open the dialog box, the default search query is this:

find changeset where date > '5/27/2020' on repository '<repo_name>@<server_name>:<port>

(today is 6/26/2020)

For some reason it always defaults to only show changesets from less than 1 month in the past. Seeing as xlink is primarily used for reusable, modular code, this means there is almost never any changesets shown. So in order to find the latest changeset you have to click "Advanced" and remove the date clause manually.

Personally, I'm aware of this quirk and I know how to fix it, but this has caused problems in the past for less experienced developers and it pretty much ensures that they will not be able to figure out how to xlink a module without my help.

A better way to do this would just be to show the last 20 changesets or something. Constraining it by date is extremely short sighted (heh) and unnecessarily confusing.

If I complete these steps:
1. Create repos B and A
2. Commit file foo to repo B (this becomes cs1)
3. Create xlink /b in repo A as -> cs1@/main@B (writable)
4. Create branch /main/task001@A
5. Checkin several files without touching /b

I can then complete my task branch like this:
6. Switch workspace to /main@A
7. Merge from /main/task001

After this, B will still have only one branch and one changeset, because no changes were made inside of /b. Wonderful!

Alternately, I can complete my task branch like this:
6. Merge-To from /main/task001 into /main@A

This is a better process. It has fewer steps. In fact, it is recommended by the Plastic Book. Unfortunately, while it should behave exactly the same, there's a small difference: This process has just created a new changeset #2 on repo B that is a merge from cs1 and contains nothing.

This empty commit is dangerous, because Plastic doesn't support making empty changesets and therefore doesn't account for them in many of its behaviors. Just today, I had done the following:

1. merge-to from /main/task123 to /main (xlink gets cs:N+1)
2. merge from /main to /internal (this didn't change the xlink, it still points to cs:N, which is probably a bug)
3. Modify contents of xlink
4. Attempt to commit

The result is that Plastic sees we are on cs:N but cs:N+1 exists, so it stops the commit and demands that N+1 is merged into N first. However, because N+1 contains no changes, the merge cannot take place. The checkin is impossible until I shelve the changes, change the xlink to point to N+1, reapply the changes, and try to commit again.

It is also a problem that if you merge-to /main into /task003, for example, you will also get an empty changeset on a newly created /task003@B, which clutters the B repo. That's particularly bad if B is sync'd to a public Git repo.

In the Plastic GUI, "Add format" provides the following options:

• Branches with pending merges
• Active branch in this workspace
• Custom branch query rule
• Custom changeset query rule
• Custom label query rule

cm find, however, supports additional objects beyond "branch", "changeset", and "query". I would like to highlight changesets that contain merge-links from a specific branch, but currently the only way for me to do that is to run the query in the command-line, use the query results to apply attributes, and then use the attributes for a rule that colors the changeset. It would be more straightforward if I could just use in the GUI all of the same queries that can be used from cm (or, at least, merge queries).

When it comes to text files, the embedded diff viewer is extremely helpful, allowing me to quickly click between files and see what changed. While it is possible to specify external tools for diffing non-text files, it is currently not possible to do so with the same ease of use or convenience. Embedded Diff and Custom Diff are currently mutually exclusive.

This request is to add an extensibility mechanism for the embedded diff viewer. I am thinking of this similarly to Windows' IFilter mechanism that allows custom preview renderers to be specified for any file type.

For example, if I wanted to diff a custom binary serialization that my company uses, I could write a program that converts it to text. Perhaps the program outputs the text to std-out, perhaps to a temp file - either way, Plastic would take that output and feed it into the standard text diffing feature. Similarly, it would make sense to provide the same functionality for images. In order to see diffs for 3MF files, I would specify a program that converts 3MF to BMP.