We have been making tests by selecting one file type and checkout works perfectly.
However, we want to lock more than one type, and after writing something such as: " *.h, *.uasset " on the rules field the checkout stops locking the file for everyone else.
Hi,
You can configure as many lock rules as you need. In your Plastic Cloud panel, you can check some examples about how to configure it:
Regards,
Carlos.
We are having this experience and it drove our team crazy this week causing multiple hours of conflict when we realized multiple of us had the same files checked out… We are using plasticSCM cloud, the newest unreal plug-in from GitHub (1.8.0 for UE5.1), and the Gluon GUI.
Our conclusion is that the web UI to config the lock file, or the option to manually type in a list in Gluon, is completely broken. It probably does some input sanitization that breaks everything. Whether we tried writing the rules organization wide or repo specific, touching anything about the lock file rules on the dashboard.unity3d.com site will break locking altogether.
The only thing that seems to work is to remove all lock rules, then from within Gluon app only, right click on a file and select “Lock and Checkout”. If this file type is not yet known to the lock file you will get a dialog box asking if you want to add a lock file rule for this file type. Leave the first radio option selected (ex. “Lock Files matching *.umap”) and press OK. If you look at the web interface now you will see a repo specific lock ruleset.
You can continue to add file types this way (e.g. now right-click a .uasset file or a .png in Gluon and preform the same steps) building up a filetype set in your lock rules.
If you then go look at the web interface you’ll have a lock rule for the repo that looks like *.uasset *.umap *.png. Notice the lack of commas and only “spaces.” This conflicts with the “Generate common rules” in Gluon and the web UI that show commas and spaces. Now if you try and edit this set of rules on the site using spaces, or commas and a space, between file types everything breaks.
Here’s the fun part. Delete all your rules and use the right-click method to make things work again. Click to edit the lock rules on the website, but don’t type anything new. If you open up Chrome dev tools and inspect the input element there are newline characters not spaces between asset types!
This lines up with the docs pointed to above where there is multi-line text input. But there is no multi-line text input on the website or in the Gluon UI!
TL;DR Changing lock file rules manually is busted right now. If we erase all rules from the org and the repo and only add them through the Right-click > Lock and Checkout > Lock Files matching …" option in Gluon everything seems to work.
It’s pretty embarrassing that something like this shipped. If someone just added two filetypes to the lock file via these text entry fields in Gluon or on the web and tried test it they should have noticed nothing got locked (even by yourself! cm listlocks --server=whatever@cloud shows no locks once you try and change the lock rules). Please fix this and test your software next time.
Hi @jonslime ,
Thank you for reporting this. There does appear to be an issue with creating lock rules in the Unity Dashboard right now. I have logged this as a bug with the highest priority.
The only workaround is to create the lock rules individually with the Lock and Checkout method that you mention, either in the Gluon UI or the full Unity Version Control UI.
@jonslime , Im happy to let you know the issue with Unity Dashboard has now been resolved.
Great! We’ll give it a spin
We ran into a similar issue today and I wanted to post here for anyone who stumbles across this post wondering why file locking isn’t working anymore.
It is related to the new ability to add lock rules per repo now. (Cool feature, thank you, but also it broke things) In our case, the lock rules we had in place already for our entire organization were being ignored and then also caused the ones we tried to add to each repo to be ignored during troubleshooting. We had to wipe the organization ones and copy those individually to each repo instead of leaving the main one blank. I even put a #DontPutLockRulesHere in the organization rules to remind ourselves later.
Please there has got to be a better way to catch this stuff before rolling out the new features please. We have been using Plastic for 5 years now without any major disruptions like this and is starting to eat away at the trust of Unity Source Control’s ability to maintain stability moving forward.
Side note, the gui as of 7978 is not showing other people’s checked out files, but at least with the fix I mentioned above it still does actually lock the file.
Hi @TPGZuko ,
Sorry to hear you are experiencing problems with lock rules. I wasn’t able to reproduce the exact behaviour you were reporting, but I did see some other behaviour that I have shared with the development team as a bug (i.e. trying to check in an organization-level locked file would cause an empty changeset to be created)
If you have a reproduction case for the behaviour you report, please share this with us at support so that we can get this fixed.
