Hi everyone,
I have been waiting for smart locks a long time, and I’m very glad it’s finally there.
But I can’t seem to have a productive workflow with it.
An example:
I change a few files save them and realise they need to be locked so as to avoid others to modify them before they merge my branch.
So I try locking from Workspace explorer, turns out it’s impossible because the file is checked-out and I need to revert my changes then take the lock then reapply my changes.
=> seems like an incredible hassle.
Also another remark: I think we need to be able to lock from pending changes, because nobody is going to navigate to every single file in workspace explorer.
The feature is otherwise sounds, seems to me with very few UX improvements it will be perfect
It doesn’t seem to be realted with Smart Locks but also with the legacy lock system, right?
If you enable file locks, you will need to change your workflow to always checkout the files before modifying them (you can force it if you are using the Unity Version Control package).
It doesn’t seem to be realted with Smart Locks but also with the legacy lock system, right?
I don’t have experience with the legacy lock but you are probably right.
(you can force it if you are using the Unity Version Control package)
If it’s possible to do so via the package I am surprised it’s not possible to do it via the plastic client. I am talking from a perspective of someone who cannot use the Unity version control package.
Currently if you merge from a branch that has a retained lock on a file, and it has a conflict with your current branch, and you keep the destination version rather than the locked version, you enter a stuck state where your branch does not have the latest locked version of the file, but you’ve already merged from that version and can’t merge again.
This scenario is causing problems for us, and it’s hard to resolve because you have to manually release the locks and create them again in the resolved branch, which is hard to do for a lot of files.
I think in this scenario, resolving the conflict should move the lock to the resolved CS and the latest version should be considered the version in the merge CS.
We have just run into and resolved another locking issue where two different users on the same changesets were getting different results trying to checkout a file.
User A could lock and checkout the file, and undo, no problem.
User B when trying the same thing, got “Cannot checkout because you don’t load the latest version in /main” even though both users are on the same changeset with no pending changes.
For context, at this point the latest version of the file is on the branch that both the users are on, but there is no lock present.
Eventually, we did a workspace update on User B, and even though it did not find any new changes, all of a sudden user B can now lock and checkout the file.
I’m still not sure what happened here and it cost us hours to debug. What could have caused this?
You can also check-out the items via the Plastic GUI. But you need to remember to do it before editing the files on disk with your editor.
The process is very cumbersome:
After realising you need to lock say, 10 files that already have modifications
Revert the changes on the 10 file through “pending changes”
For each of the 10 files do:
Locate the file in the “Wokspace explorer”
Lock it
Redo the changes on the file
Commit
I cannot ask that of my team, that would be really hard on people especially those who work on many files at once, and/or if every single one the10 files are in different folders.
Hi @TournesolBancal , if you want to use file locks, you need to switch to a Checkout/lock → Edit → Checkin workflow.
This is not something related to the new Smart Locks feature but also related to the legacy lock system.
If you use the Unity plugin (or some other plugin), yu can configure it to force users to lock the items before editing them.
But if you are not using any supported plugin but some other editor/IDE that Plastic is not aware if it, you will need to checkout the items before modifying them.
Ok, thanks for the quick replies.
I will re-evaluate the unity plug-in and keep you updated with the results.
I must say this does not feel like a great solution though.
We just tried using the new smartlocks and now are completely stuck. We have 3 branches, one that has the full code set that we’ve only been working in (Development - it is also the “destination” as mentioned in “retained”). We added a rule just for *.unity files (scenes), and then checked out + locked them. Not a single person can check them back in or unlock them. I’m the admin and can’t do it from the dashboard or locally. The original dev can’t do it either. It just says only an admin can do this and in the dashboard says to “check the logs” (except, you know, it’s a login to the UGS service and I don’t have access to Unity’s logs). It says the files are “retained” and there’s literally nothing we can do with them. How can this be resolved asap? We have multiple deadlines coming up and unfortunately tried to add this to our workflow and it failed immediately and spectacularly.
So I got stuck unable to checkout (and thus commit) files because I tried to branch an old version of a project and it required me to merge with main first (which I absolutely don’t, ever, want with this branch).
This is a note to myself (and whoever needs it) for when I run into this again, to get out of this mess:
Click “Workspace Explorer”
Click “Show Locks” (top right)
Click “Configure rules”
Click “New rule”
Select the repository in question
Select the main branch for “lock destination”
Click “Generate common rules”
Put “*” in “Branch exclusions”
Press “Save”
This disables smart locks and those weird checkout restrictions for the entire repository.
Now you can check in/out again as you need to and make your deadline.
When done, you can delete the rule again, and hope you won’t run into this again.