In the Changesets view, have a split view, that shows the filenames of the files in that change set.

The view could be just like you use in the Pending Changes view, where the split is resizable, with the top half showing change sets, and the bottom showing the files in the changeset currently selected. That way you can quickly arrow up/down through the change sets and see the files instantly in that set.

If you want to get to the diffing tool, you still need to double click the changeset. This is only about showing the files in the changeset.

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.

When trying to switch the workspace to a different changeset/branch, the user is first asked if he's sure, but then gets an error if there are pending changes.

It would be great if the question dialog would show how many pending changes there are (and maybe a tooltip with a list of all changed files?). Then, if the user decides to go through with it anyway, the pending changes should be reverted (maybe have a checkbox, so the user is really sure) and the switch should be performed.

When there are no pending charges, the switch should just happen without asking.

I often have loose files that got changes by the IDE or Unity that I can safely discard. Having to do this manually every time can be quite annoying when quickly zapping through different changesets.

I propose that Plastic Cloud offers an incremental backup method. It should export backup data to customer-provided cloud storage (AWS S3 / Google Cloud Storage / Azure Storage), perform backups with high frequency (possibly with a combination of full / incremental backups), and only leave the responsibility of validating these backups with the customer.

Our use case:

We use Plastic Cloud instead of Plastic Server, because it reduces our operational overhead. Plastic Cloud is great in many ways, but using it means that we also entrust the responsibility of availability, security, as well as backups/disaster recovery with Codice Software.

As our organization grows larger and older, we need to have shared responsibility for backups/disaster recovery. If we ask ourselves, "do we have backups?" then we must be able to answer "yes, and we have verified that they are not corrupt", not "yes, we trust that another organization does it for us".

It is possible to handle backups today: run a local Plastic Server, scan the Plastic Cloud organization, replicate what's in there to local repositories, then archive the local repositories. However, that requires a fair bit of operational work.

I would like to see that Plastic Cloud offered an 'automated backups' feature: I provide details on a customer-controlled cloud storage bucket in a cloud provider like AWS/GCE/Azure, and credentials that allow Plastic Cloud write-only rights to the bucket (without the rights to modify what's already in the bucket). Plastic Cloud would then regularly export changes to the bucket. For example, a full export once per month + an incremental export once per day. I would like notifications to be sent to me (for example via emails) whenever there is a problem with export process, as well as summaries of this somewhere (for example within the weekly digest emails that are sent out).

I would like validation to be left with the customer (although someone will probably ask for some degree of automation here as well). As such, I expect that I can restore a backup - or perhaps part of a backup, like, only a single repo - into a local Plastic Server and then be able to access the contents directly.

The automated "export to cloud storage bucket" process will allow us to easily implement any process we would like for further backups (for example, manually copy backups from cloud bucket to offline storage).

It would be helpful to be able to be able to get some idea of the contents of a backup without needing to perform a full restore. (Example: which repos are inside the backup? what is the range of changesets contained within the backup?) This could either be a tool that inspects the backup files itself, or additional text file(s) that are written at the time when the backups are created.

One nice side effect of a backup mechanism like this is that it provides us with the ability to recover from some of our mistakes, that would otherwise require contacting Codice support.

The feature requires additional backend-side processing and network transfer. We are happy to pay extra for this.

(Slightly related, there is a cloud-to-cloud backup service for GitHub: https://backhub.co/ - this has a much broader featureset than suggested above, but it demonstrates the core need.)

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

Searching in Visual Studio allows me to set multiple search terms separated by a space in order to better narrow my results. This is helpful if you aren't sure if the name of the file is "ProjectXMLData" or "ProjectDataXML", but you know for sure it has Project and XML in the name.

Attached Images
- VSSearch01 - Shows searching for all 'project'
- VSSearch02 - Shows adding 'xml', but not as an exact match. The results are still displayed as expected
- WSSearch01 - Shows searching for 'project' and results show as expected
- WSSearch02 - Shows adding 'xml', but no results are returned