Project settings will not let me check out any of the setting files.

Unity Engine
1

Apologies if this is in the wrong section, I’m not sure where to put it as I don’t understand what part of unity/perforce broke.

Hello, running Perforce and Unity 2019.4.20f1

The entire Project Settings window appears to be unable to check out any files for modification. They all say “Locked Remote” at the bottom, and if I press Check Out button, Unity just reports 1 file (whatever that particular screen would edit) could not be checked out for editing.

How do I fix this issue? I need to swap our project rendering into URP from standard, and this is holding up ALL our work. Not to mention I suspect future project use will also need to get to these files, as they seem important for build settings, etc.

Things I have tried:

  • Closing Unity entirely, using P4V to Pull the latest of all files down in the preferences directory. Didn’t fix anything, still won’t let me edit the files or check them out.

  • Using Unity to push all my changes to the Perforce server. There are no changes to push, and so this gets nowhere.

  • Manually modifying the preference files read only flag. This just messes up Perforce and Unity just resets them to “Locked Remote” once it boots up again.

2

Ok, I half salvaged it so far through a bit of intuition and a bit of an admittedly sledgehammer approach.

I deleted everything in my local copy, EXCEPT for the following:
-Assets
-Packages
-Project Settings

  • and the root files of the project (.p4ignore, .vsconfig, the .sln, etc.).

Then, with unity editor CLOSED, I opened up P4V and just pulled the last stable version I had on the workspace down to my local machine. Closed P4V after just in case it breaks stuff.

Opened Unity editor. It loads the project, there were a few errors, missing packages, whatever along the way, slowly fixed them bit by bit till I got something that compiles and can run in play mode. (We have lots of packs like VRIF that are non-trivial to fix, so I won’t bother with instructions as this would be unique to each project.)

Critically, by wiping all but the above, I now have a LOCAL version of the project that is currently not logged into Perforce. To be exact, Version Control is set to “Visible Meta Files” instead of logging into our Perforce server. This lets me edit, import the URP packages, setup our rendering preferences, etc. without needing to check out any files. I was able to salvage the project and can run it locally, edit the built scenes, and presumably make a build (I didn’t bother testing this yet as android builds for VR can take…a while, lol.)

Currently making a full backup locally of this project folder that is working. My next hurdle is figuring out how to convince P4V to apply all the changes to the remote server version. If I can do that without breaking the Unity Editor side of things, that should get our team up and running again. I’ll be back to report how that goes soonish. (Large project = lots to back up.)

3

Well, that didn’t work. All of project preferences are still marked with an “Added Remote”, which is an improvement but still not functional.

Looking over p4v, I suspect multiple projects over different perforce Workspace got mixed up into a single depot. There are pending changes to the depot that are from an unrelated project in p4v. I’m going to see if I can remove that project’s changes (it’s a test project and is of no loss if we lose it from the depot.)

4

I haven’t used P4 since 2007 but it was always painful when IDEs didn’t smoothly integrate, and files would get stuck locked, or checked out for delete… plus the branching was just insane, IIRC.

Are you married to P4? I’d ditch it and use git, it just plays so much nicer with modern computers / operating systems.

We used to do this just by chekout-all, drop on top, then commit all or something. It was pretty slick and p4 would figure out what didn’t change.

I’m sorry you’ve had this issue. Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.

Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).

You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.

As far as configuring Unity to play nice with git, keep this in mind:

https://discussions.unity.com/t/736093/3

Here’s how I use git in one of my games, Jetpack Kurt:

https://discussions.unity.com/t/807568/3

Using fine-grained source control as you work to refine your engineering:

https://discussions.unity.com/t/826718/2

Share/Sharing source code between projects:

https://discussions.unity.com/t/719810/2

Setting up an appropriate .gitignore file for Unity3D:

https://discussions.unity.com/t/834885/5

Generally setting Unity up (includes above .gitignore concepts):

It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It’s simply ridiculous not to back up.

“Use source control or you will be really sad sooner or later.” - StarManta on the Unity3D forum boards

1 Like
5

SUCCESS! We can edit things in project preferences again!

The cause was that one of us made a “test of perforce” project (just an empty unity project) but set it up within the same depot as this project’s depot. So there was pending changes to all the default Unity stuff like project preference files, etc. that would never be resolved by loading our main perforce projects.

1 Like