Trond

Hello, Some time ago I got a tip on this forum to look into CmdRunner to improve performance for custom tool integrations. I am currently testing out https://github.com/PlasticSCM/plastic-cmdrunner , and while it seems to have better performance, I have some worries it would be nice to have cleared up: The repo hasn't had any updates for 5 years. Is it still actively maintained? There are a couple of long-standing unresolved issues, particularly this one (I'm not usually working on Windows so it's a bit cumbersome to test given that there's no specific repro-steps I realize there are kind of repro steps by re-reading the issue again), which I'm not sure if is still a problem, or if the suggested fix is causing any unexpected side-effects: https://github.com/PlasticSCM/plastic-cmdrunner/issues/1 While Mac is our main development platform, some of our team members occasionally work on Windows, so I'm not sure how likely we are to get affected by this. There's no license attached to the repo, so I'm a bit hesitant to use it for production (I filed an issue about this). Edit: FWIW I would very much prefer the CLI tools to be fast enough to not need this kind of wrapping. Are there any plans on looking into this? The conclusion from this thread was that it's caused by application launch overhead: https://forum.plasticscm.com/topic/23494-cli-tools-slow/#comment-46676 Using the CLI tools manually works okay-ish, but it's incredibly much slower than say Git just to get the current workspace status. Best, -Trond

@calbzam has been very helpful looking into my issue and providing helpful pointers. Conclusion is that most of the time is spent in application startup overhead, and it's recommended to use "cm shell" or CmdRunner https://www.plasticscm.com/documentation/cmdrunner/plastic-scm-version-control-cmdrunner-guide for better performance, neither of which I was aware existed - thanks @calbzam!

@calbzam Sent PM regarding "cm status"-log @Héber Attached log: iostats.log

Hello, We've recently built some simple convenience tools on top of the CLI tools provided with a standard Plastic client install (cloud edition). The problem I'm facing is that they seem to be unexpectedly slow. For example, running "cm status" in a very small Unity project* takes between 1.5s and 2s. This might not seem like much, but when trying to integrate this with other tools, things start to feel sluggish. Are there any settings that can speed up client side operations like this? Note: Running on M1 MacBook Pro, seems like the executable is Intel. Is Apple Silicon available somewhere/planned? * standard Unity folder structure, ignored Library and the usual stuff, a few scripts and very simple prefabs, Assets-folder being ~130k

Hello, thanks for the reply! It seems to mostly work, but sometimes files do not appear that clearly are changed. I will keep an eye on it and see if there's a pattern. Best, -Trond

I just today installed the most recent version (11.0.16.7080) of PlasticX for Cloud on macOS Monterey 12.2.1, coming from the "legacy" UI client. I've noticed that the client does not update the pending view correctly. Both Unity and the command line client shows correct pending changes, but the PlasticX client does not, even clicking the refresh button or going between views. Killing and restarting the client makes it work, but it's very cumbersome. Is this a known issue?

Just wanted to say that our team is very interested in this! We're missing this feature from the Plastic SCM plugin from the Unity asset store, which is no longer available.

Hello, We managed to install 1.17.0 via the "package name" option (tried both 2021.2.8 and 2021.3.5), note no version specified: The error message that comes when trying to edit assets that I have a lock on no longer appears. This error message actually appeared to be a wanted feature for us in 1.15.18, as we initially thought it was blocking us from doing changes to assets other team members had locked, and it took a while until we realized it happened on assets that was locked by ourselves. Reading this thread, however, my understanding is that no such feature (blocking edit of remotely locked assets) is supported yet: The now deprecated, unavailable Plastic SCM asset store package used to have this (and a simple way to turn it off) - not having it any more has caused some wasted level design time due to not being blocked until commit-time, so we're very interested in getting something like this in the near future. Best, -Trond