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

Currently, when I'm on a branch and I want to merge what I have to another branch (e.g. main) I have to right-click on my current branch/changeset, select "merge from this [] to..." and then pick the target from an endless list of all my braches.

This is incredibly error-prone, but still somewhat faster and more convenient than switching to the target branch and then merging from the branch I've just been at.

What I'd like to see is when I right-click on another branch/changeset (that I'm not on) that I get the option "Merge to this branch/changeset...".

This might seem like a small improvement, but given how often we do this, it'd definitely help. An option setting to also then switch to the target branch when doing this might be a plus (I noticed someone else asked for this before).

Our usual workflow is to first merge from main to the current branch, sort out merge conflicts, check the build, etc., commit fixes and changes if needed, and then merge back to main.

In the branch explorer view you have essentially two sections. The graphical chart on the left and the properties panels on the right.

Assigning attributes to branches is very handy for keeping track of things like status and work type, but currently you can't see those attributes "in a big picture" as you have to click on the branch and then look at its attributes in the right hand panel.

What about allowing us a Display Option to draw the attribute name and value in the main chart right underneath the branch? This would allow for seeing the information on multiple branches at a glance and help with the big picture.

I hear from my designer-y people that they'd like to be able to experiment with features before checking them in to the cloud. Naturally this can be done with branches with the regular plastic, but I'd like for them to keep utilizing the simplicity of gluon.

I don't have a solid suggestion as to how to implement this, but as an alternative to checkin you could provide a "experimental checkin" action. Gluon still behaves as normal, but these checkins are only present for the user. When the user is done experimenting, they can checkin their experimental changesets to the cloud or abandon them alltogether.

Like I said I don't know if this is feasible, but it would be a handy tool for the linear workflow gluon provides!

Now, the update triggers only provide a path to the workspace being updated.
Having access to the old and new changeset-id's opens up quite a lot new possibilities.

For example, in UE4, when working with plugins in a code project, they are compiled automatically at first. When making code changes to the plugins, they are often not automatically detected which causes the engine to crash at startup.
Deleting two specific folders makes the engine recompile those binaries automatically and thus fixes this inconvenience. Unfortunately, this process takes about 5 minutes on average so doing it after every update is not feasible.
By providing a specific string/tag in the comment of checkins that require a compile, we are able to only recompile when necessary.

In order to make this work, we have to write out the current changeset-id to a file in the before-update trigger. Then in the after update trigger, we get the current one. Finally we would use the find command to get all changesets in between those two and check if any of their comments contain the tag.

We are already able to access the current changeset-id with
cm status --nochanges
and some parsing. (Although this could be made easier.)
Thus, only exposing the future changeset-id in before-update and the previous changeset-id in after-update would suffice.

Thanks in advance

When I use a local repo, i should to download all branch-related data locally. Then i don't need it anymore (for example, it is rejected branch or we totally switch to the new parallel branch, or something else). But I have no ability to locally remove them. I fully understand that deleting branches from repo could cause troubles for whole tree, but what if i remove only local copy of that changesets/branches?

Of course I can locally remove all changesets and then whole branch, but it is such uncomfortable and if later i will want to switch back - it will be very hard to do. Moreover, i should to hide that branch from my sync view and remember about that all the time i still have a chance to switch back.