0
Fixed

Issues with version control

Giometric 3 years ago updated by Lazlo Bonin (Lead Developer) 3 years ago 7

A couple of issues have come up when using Bolt in a project along with source control (Perforce, in this case).


1. Bolt demands to run the setup wizard on every computer that downloads the repository

This one isn't horrible but it is kind of annoying. The unit options database is present and everything appears to work, but Bolt still constantly pops up the "you should run the setup wizard!" window on any new computer. When pushing to source control, I made sure to get both the Assets and the Project Settings folders. Where is bolt storing its "I've been set up already" state on the first machine that it is somehow not coming through in the Perforce-downloaded copy? Or, is it expected that all users must generate the unit options database on their own machines?


2. Bolt then fails to run the setup wizard because it doesn't account for its files being read-only

A continuation of the first issue, this one is a bit more of a problem. Some version control software, like Perforce, has all files locked (marked read-only) by default, unless they are explicitly checked out. Bolt does not appear to check for or deal with this situation, as the setup wizard fails with an IO exception on the machine that downloaded the project through Perforce, because previously-created copies of the generated files came down with it, and were marked read-only. We had to go into Bolt's files and manually delete the file so that it could proceed.

Removing the read-only mark would also work, and is something that could be done in-code by Bolt automatically. Alternatively, if the expectation is that the unit options database and other Bolt-generated files are not supposed to be on version control, there should be some information in the documentation about that so we know not to include them (though IMO it's bad form to put anything within a Unity project's Assets folder that should be excluded from source control).

Bolt Version:
Unity Version:
Platform(s):
Scripting Backend:
.NET Version (API Compatibility Level):
GOOD, I'M SATISFIED

Thanks for the fast response!

Satisfaction mark by Giometric 3 years ago
Pending Review

Hi Giometric! Sorry you're having this issue.

1. The setup wizards will show if the project settings files are missing. Have you sure you committed Ludiq/*/ProjectSettings.asset to version control?

2. Can you paste the stack trace of that error specifically?

Hey Lazlo,

I don't believe we missed any project setting files, but it is possible we didn't do a "Save Project" or something like that, so I'll double check and have that user try again, should be able to confirm by a little bit later today.

I'll try to get the original stack trace some time today as well, but for now I am able to reproduce this issue (or, at least what I believe is the same issue) by running Tools > Bolt > Update Unit Options. In this case, another user created a custom unit, and I made some edits to the script on my machine and wanted to run that command so that the graphs would be updated to reflect the changes. Here's the stack trace:

UnauthorizedAccessException: Access to the path "/Users/giovanni/Projects/CombatSystemTest_Flow/Assets/Ludiq/Bolt.Flow/Generated/UnitOptions.db" is denied.
System.IO.File.SetLastWriteTime (System.String path, System.DateTime lastWriteTime) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.IO/File.cs:487)
System.IO.File.SetLastWriteTimeUtc (System.String path, System.DateTime lastWriteTimeUtc) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.IO/File.cs:493)
Bolt.UnitBase.Update () (at C:/Users/lazlo/Projects/Ludiq/Bolt.Flow/Editor/Options/UnitBase.cs:313)
Bolt.UnitOptionsWizard.UpdateUnitOptions () (at C:/Users/lazlo/Projects/Ludiq/Bolt.Flow/Editor/Windows/UnitOptionsWizard.cs:51)

Checking the file out in Perforce to make the UnitOptions.db file file non-read-only gets it working again.

So if I understand correctly, you want Bolt to force the file to become writable, even though it was previously marked as read-only by Perforce? That's easy enough to do, but I want to make sure I understand the goal here (I'm not used to VCS that lock files).

Edit: I would be adding this line to the unit options database generation code:

new FileInfo(BoltFlow.Paths.unitOptions).IsReadOnly = false;

Correct; that said, I hesitate to recommend that directly, as it is true that the file is marked read-only by Perforce for the explicit purpose of preventing people from changing files without checking them out first. In Perforce, you 'check out' a file to let the server know you intend to make changes to it, and once you do that Perforce removes the read-only mark. Then you make your changes and submit the changelist to check the files back in, which marks them read-only again. If for some reason you manage to change/delete files without checking them out first, you can still run a 'reconcile' in Perforce so that any files that no longer match what the server has can be picked up and put into a changelist.

In part it's a workflow/preference question - Unity itself totally ignores read-only marks on files and happily stomps on them if the built-in version control plugin isn't being used. What I typically do is work with Unity, which will overwrite assets and settings files as it pleases, then go back and do the reconcile later. In the case of Bolt's UnitOptions db and other generated files, I don't always necessarily know which files it's going to try to overwrite, so it's a bit more hassle to try to get them all checked out beforehand.

Not everyone will want to work like this, I suspect, so maybe silently overwriting the file isn't necessarily the way to go, but I would like the option at least for Bolt to do the overwriting for me. A good middle ground could be something like a confirmation prompt that pops up and advises the user that the unit options db / other files are currently read-only, and asks whether the user wants to force the file operation (this is what Visual Studio and various other apps do, for example).


On Issue #1, I was able to go through the Perforce process with the other user again, and it looks like that one was in fact user error on our part. We most likely skipped a file at some point, and the Perforce copy of the project didn't have the entire setup, causing other users to have to go through it again. We're doing another test where we're further updating the unit options db to confirm all this for sure.

+1
Working on Fix

Thanks for the in-depth explanation! I usually have Bolt follow Unity conventions, so I will make it change the file to writable to avoid this (I believe you're the second user to ever report this, but it's a common enough use case that I want it to be as simple as possible).

I'll have to look at other generated files to make sure they also get the same treatment.

Fixed in Alpha

Done! All files generated by Bolt will be made writable automatically starting in v.1.4 Alpha 2.