Saving locked files w/o checking out (Perforce)

FMOD Studio
1

We are using the Perforce integration in FMOD Studio, and as we do with the rest of the game, we have many FMOD files set to exclusive checkout. This includes events, so that people don’t accidentally work on the same event at once. We noticed today that exclusive checkout is not working in FMOD, causing situations where someone can easily lose their work.

Here’s the situation:

User A makes changes to an event and saves their work.

  • P4V checks out the event automatically
  • A checkbox appears near it in the FMOD event browser
  • A grayed out checkbox appears next the event on User B’s computer

All of this is as it should be. But there’s more to it:

User B does work on the same event, not realizing that it is already checked out by User A. User B saves the project and closes FMOD. Later they reopen it and do more work on the event.

  • FMOD saves the changes to the event when it is closed
  • Those changes are still there when FMOD is reopened
  • The event does not appear in User B’s pending changelists
  • The checkbox in the FMOD event browser stays grayed out

Aside from the checkbox in the FMOD browser, all of that behavior should not be possible. If you save an event, Perforce should check it out automatically if it can. And if it cannot be checked out, FMOD should not be able to save it because that file should be set to read only.

Here’s where it’s really bad:

User A checks in their changes, and User B gets latest. The file on User B’s computer gets overwritten with the version of the file that User A just submitted. User B gets no warnings because they do not have it checked out, so as far as Perforce is concerned, the file is identical to the previous depot version. This means that User B loses all their work, and it cannot be recovered either because it was never in the version control system to begin with.

This is a problem that can be pretty devastating, particularly because it fails silently. When you’re working on more than one event, and you check yours in at a different time than the other person, you have no reason to think your changes weren’t submitted, especially when submitting a changelist full of files only named with their GUIDs. You don’t even get to resolve the differences like you’re supposed to have to, you just don’t have that file in the changelist at all.

FMOD shouldn’t be able to save that event when you save the project. You should be notified that you can’t save a read only file as soon as you try to save it. Actually, FMOD is supposed to check the file out when you make your first change, so you should be notified then when it fails to check the file out.

Is this a bug? Is there something about setting up exclusive checkout that we may have missed? This has caused problems for us already, but fortunately nothing too serious. I’m hoping to find out what the limitations are of our current workflow before something really bad does happen.

2

Hi,

Thank you for bringing this to our attention. Could I please grab your FMOD version?

Testing 2.03.14 I was not able to reproduce the issue. How is project B being closed?

Attempting to pull the changes into Project B triggered

conflict
conflict493×188 10.3 KB

Are you using the P4 app at all or is everything done through the P4 integration?

It is possible to manually lock files from the Source Control context menu:

image
image506×487 25.1 KB

That may be what you are looking for?

3

I am using 2.03.14 as well as you can see here. I have never seen that Conflict Resolution window before ever. That’s what we should be seeing to keep our work from getting silently overwritten.

image
image787×471 78 KB

As for how project B gets closed, I’m not certain, but I would imagine just Alt+F4, clicking the upper right X button, or right clicking in the taskbar and selecting “Close” from the context menu. Is there a difference between those? I do know that we tested manually saving the project before closing it and I don’t think it made any difference.

Regarding my workflow (quotes are just for organization)…

I do the following operations in the P4V app as part of my regular workflow:

  • Move files between changelists
  • Submit files/changelists to the depot
  • Revert files when I need to discard changes
  • Confirm that files have been checked out automatically (pressing Refresh after saving changes in FMOD Studio, then looking in my default changelist)
  • Get latest revisions of files submitted by others

Sometimes I also do these operations in P4V as well:

  • Diff files between workspace and depot
  • Reconcile offline changes
  • Resolve conflicts
  • Overwrite workspace files with their depot version (‘Get latest…’ using ‘Force Operation’)

I rely on the FMOD integration to:

  • Check files out
  • Mark new files for add
  • Mark old files for delete
  • Mark/create files for delete/add when renaming
  • Visually tell me if a file is checked out by me or someone else

These operations can’t really be done in P4V because the filenames are just the GUIDs there, so I have no way of knowing which one to do it with.

After comparing those lists, you’ll probably notice that the only things I use the FMOD integration for are the things that it does automatically and that you can’t do in P4V if you are only seeing the GUID filenames.

You’ll also probably notice that I don’t use anything in the Perforce submenu in the context menu when right clicking on events. This is because almost all of the options in that submenu are things I’ve never seen in Perforce before, except for the one I feel like I will never want to use anyway. I have never seen the words “Sync” or “Lock” used in P4V for any operations I do regularly, as is also the case for “Identify local changes…” I suspect that Sync might mean Get Latest, and Lock might mean setting a checked out file to exclusive checkout, but terminology is very specific and important in software, so I never wanted to find out the hard way when I could instead just use P4V. I’ve seen “Merge” and “Revert” in Perforce before, but I would never want to merge and do other operations at the same time; and I use revert all the time, but I would never want to revert the entire project rather than only a specific file. I imagine “Identify local changes…” is probably similar to “Reconcile offline work” and “Commit” sounds like it’s similar to “Submit” but they must be different in at least some way if the words being used are not the same. Consequently there is nothing in that menu that I would ever want to do, so I do all of my version control operations in the P4V app except what FMOD needs to do automatically.

Is it possible that those are the Git terms for the equivalent operations or something? I’ve actually never used Git, so maybe those words make more sense to most people, but it’s very confusing to me.

image
image404×545 20.1 KB

We have all the files in the FMOD project set to exclusive checkout in Perforce. No one should be able to save any changes to a file that someone has checked out already; FMOD should give you an error saying that the file is read only and cannot be saved. I don’t know why this is happening, and I have confirmed in P4V that they are set to exclusive checkout. Does “Lock” do something different than that? I thought exclusive checkout is the Perforce feature that is for doing that. If that is what lock is, how do we configure it to automatically lock anything that we check out as soon as it’s checked out? I don’t want to have to do that manually, mostly because I will definitely not remember to do it every time.

Thank you for your help. Sorry for the delayed response.