Thank you for the detailed post. We have documentation outlining the behavior of the options here: FMOD Studio | Using Source Control.
Oh, thank you so much, I have no idea how I hadn’t found that before. Still, it seems like some basic operations I’m used to relying on are missing, and more importantly, it seems like FMOD is ignoring some important Perforce features (more below).
To get the most out of the P4 integration it is best to try and do all operations in Studio.
I would love to, but too many features/operations are missing or implemented in ways that I don’t prefer. That said, I do very much prefer to see the files I’m working with in a human readable form, so that’s a very strong motivator for changing my workflow…
“Sync Latest & Merge Project… This gets the latest version of the project from your source control repository.”
I’ve never used this because getting latest is no different in P4V, and merging isn’t something I usually want to do at the same time, or really at all. Merging to me means two people probably did conflicting work and someone’s work needs to be discarded. The exception to that is code, but resolving those conflicts is a task in itself a lot of the time that I never want to have to do. However, I did not realize that the FMOD integration is made to merge with a tool for it that makes that task as easy and simple as it should be. (Once again, this is the first time I saw that document for some reason. I had seen a much smaller page about setting up version control and didn’t realize there was another one that was actually comprehensive, so thank you again - I had stopped searching because I thought I had already found what was there.)
But despite learning all the new information in the correct documentation, the fact remains that I don’t ever want to have to merge at all. As useful as it is, it is still the case (as your documentation says) that there are plenty of cases where there are conflicts that can only be merged by someone’s work being discarded. I don’t personally prefer being able to merge over the ability to prevent that from happening entirely. Which brings us to the next point…
Lock: Lock an opened file against other users submitting changes to the file. ( p4 lock )
As you and the Perforce documentation say, lock prevents other people from submitting the file. This means that lock does not prevent anyone from working on the file in a way that might conflict with what the person who locked the file will submit. It seems like the point of lock working this way is specifically to allow other people to continue working on a file in a way that won’t cause problems for the person who locked it when they submit. But I don’t see why that would change anything about other people being able to do conflicting work on that file before it is submitted by the person who locked it. Because of this, it is more flexible, but it doesn’t solve the problems that exclusive checkout exists to solve, which is to prevent anyone from doing any work that might have to be discarded, which is a problem we’ve been having regularly.
And according to you and the FMOD documentation, locking needs to be done manually every time you use it. I will absolutely not remember to manually lock a file every time I intend to use that feature, and I don’t assume I am the only one who would have that problem. Even if I did remember every time, exclusive checkout is a property that applies to the file itself, making it essentially automatic. Lock prevents you from using an operation in Perforce. Exclusive checkout prevents you from doing an operation on the file entirely, regardless of what program you use to do it. It is more restrictive than lock. You shouldn’t be able to save that file at all in any program because Perforce changes it to read only.
Here is a video showing exactly what should not be possible in FMOD, and confirming that Perforce is handling that file correctly:
In this video I:
- Show that FMOD sees that the event is checked out by someone else
- Make a change to the file
- Save the project (and consequently the file)
- Copy the event GUID and move to P4V
- Select the event in the depot tree by searching for the GUID
- Confirm that that specific event is checked out by someone else - both Perforce and FMOD correctly see this information
- Attempt to check out the file in P4V
- Get an error from Perforce telling me that I cannot check out the file because it is checked out by someone else
In order to save a file in the first place, it needs to be checked out. This usually happens automatically and silently, but if a file can’t be checked out, it shouldn’t be able to be saved at all. And FMOD knows it can’t check the file out, so why is it not giving me an error when I try to save it? This is much worse than having to merge conflicts, because you don’t even know you’re in conflict until you have to merge, which often means losing more work that you should have had to stop doing the first time you tried to save.
So ultimately, exclusive checkout is supposed to be a more robust way of preventing file conflicts than lock, but it doesn’t work with FMOD, meaning it has the biggest possible potential consequences in terms of file conflicts and work that needs to be thrown out.
This is missing from the docs and I have made a task to add it. It is possible to revert changes for specific events via the commit window
Ok I can’t fault myself for missing this one. I would never have thought to look in the commit window to find where to revert something. Reading the docs would have been the only way I could have possibly figured that out while still using P4V to submit my work.
Thank you so much for this reply. A lot of things make a lot more sense to me now, particularly after seeing that there was actually a properly comprehensive page of documentation that I thought didn’t exist for whatever reason.
However, regardless of the much better understanding I now have of the Perforce integration, I still think the exclusive checkout is a significantly non-trivial issue, but I completely acknowledge that that is only my opinion and maybe our team is the only one that uses Perforce and FMOD together in this way.
Unfortunately though, despite seeing that the integration is much better than I thought, and even after seeing that you can indeed actually use Perforce with FMOD and actually see the event names, I am still without question going to use P4V instead of the integration (but it’s great to know it’s easy to merge if I have to). It’s oversights like exclusive checkout not working that make me not willing to trust a third party integration. I also don’t use the Unity integration either for the most part for similar reasons - it doesn’t always behave consistently the way I expect it to, and it causes issues because of it. I only ever want to rely on tools that always work as expected, because there are plenty of times when a small issue can be more than catastrophic. When things are going normally, if someone loses their work on a couple of events, I can go write a forum post and get answers like this to keep it from happening again. But when you have less than zero time to get things finished for a publisher milestone or console certification deadline, something that small could become a devastating setback that disproportionately affects many other things that you could never have anticipated. As frustrating as Perforce can be sometimes, I know that the operations I always have to use will work. I only trust third party integrations for tasks I have used them over and over for without issues, and once I know I can trust it, I still need to prefer the workflow. I will definitely keep the FMOD integration in mind for some things a lot of the time, but I just don’t feel like I should make it part of my default workflow. Although now I have good reason to believe that merging could be an exception to this, and I will definitely try that soon.
Once again, thank you for your help. I definitely have a very different and much better understanding of the integration than I did before, but it still feels to me like it isn’t the best option a lot of the time.
