What am I doing wrong which is causing this?
Studio thinks there are 673 .xml files in the project’s /Metadata folder, and keeps adding them to my Perforce changelists, but they do not actually exist. They did legitimately exist at one point, but were subsequently removed.
They tend to not appear until I run ‘Identify local changes’, and running ‘Sync latest and merge project’ removes them.
How were they removed, exactly? Were they deleted in FMOD Studio? Through P4V? Or in FInder or Explorer? Each of these methods will result in FMOD Studio and Perforce reacting differently to the files’ absence.
Out of curiosity, what circumstance led to the removal of so many of your project’s files?
I don’t know. I assume that by the time I noticed the problem, the files had already been deleted.
I only ever add/delete the metadata files via the Studio interface.
673 files is not a large number to me… 
Probably when I made a change to a whole group of events, I imagine. I think at one point I mistakenly created events from a large group of newly-imported assets as “Make one event for each asset” instead of grouping them together. Something like that.
Unfortunately, without knowing how these files came to be in their current state, it’s difficult for us to pinpoint the cause of this issue.
Still, it seems clear that the copy of the project in your local Perforce workspace has gotten out of sync with the copy in your perforce repository. Here’s some steps that may help:
Try to avoid using “Identify Local Changes” until you have gotten your workspace and revision control sever back in sync; its entire purpose is to identify differences between your local copy of the project and the one on the server, so if files are present when they shouldn’t be it’ll naturally pick them up and mark them for add.
Good info, thanks.
The reason I have been using ‘Identify Local Changes’ fairly often is that frequently P4 is unaware of the .xml-file changes until I use it.
Validate generally produces this result:
One guess I have is this:
There are two machines using this project. It could be that the second machine added the files back after they had been deleted; I normally only propagate changes in one direction (From the primary machine to the secondary), but it is possible that it was done in the wrong direction at some point…
I just now experienced the following sequence of events:
I examined the server and local depots, and found that a bunch of events, two banks, and a folder I had deleted had .xml files in the server depot which did not exist on my local machine.
I tried to force-get one of those files from the depot, but could not. It simply failed with no explanation.
I manually deleted (checked out for delete within P4) all those files from the P4 server depot.
I ensured they also did not exist on my secondary machine.
I re-checked all three locations: My primary machine, the server depot, and my secondary machine. The files did not exist in any of those three locations.
I started Studio. As expected, none of the things I had deleted were present in the Studio interface.
I ran ‘Validate Project’. After that, the situation was the same. I closed and re-opened Studio. Same.
I ran ‘Sync Latest & Merge Project’. After that, the situation was the same. I closed and re-opened Studio. Same.
I ran ‘Identify Local Changes’. After that, P4 had a changelist with 1543 metadata .xml files in it: 802 ‘AudioFile’, 2 ‘Bank’, 736 ‘Event’, 1 ‘EventFolder’, and 1 ‘SnapshotGroup’. None of them exist in either the server depot or either my machines. They seem to all be things I have deleted from the project (from inside Studio) at some point.
So the important questions are:
1 - Where are these file references being stored, and why won’t they die?
2 - Is the ‘Identify Local Changes’ function simply something one should never use? (That would be a shame, since it is sometime the only way to get new metadata files to show up in the changelist other than searching for them manually.)
3 - How can I expunge all memory of these obsolete files from Studio so that they cease to appear?
This should never happen unless you are working offline, i.e.: making changes to your FMOD Studio project while unable to connect to your P4 server. Are you regularly working on your FMOD Studio project in situations where your machine is disconnected from the network that contains your P4 server? That might explain why .xml files are being created but not showing up in your changelists.
FMOD Studio is generally capable of merging changes and handling conflicting changes; if you submit and get latest on both machines, both machines should end up with exactly the same files.
As far as I’m aware, this is physically impossible.
Identify local changes checks through the files on the local machine and compares them to the files on the server, assumes that any differences found locally are offline work that needs to be checked in, and adds the changed files to a changelist. If the files are marked as changed or added, they must be present on your local machine; wheras if they’re marked for delete, they must be absent from your local machine but present in your perforce repository.
The files are either on your local machine, in your perforce repository, or both. The files wouldn’t show up, otherwise.
When you check your workspace in P4V, are you sure you’re checking the same workspace that’s used by your FMOD Studio project? Similarly, are you sure that the repository that you’re viewing in P4V is the same one used by your FMOD Studio project?
Identify Local Changes is designed to identify changes that have been made locally while not connected to your Perforce server, as can occasionally happen in the event of a network disruption or working on a portable computer.
It should not be necessary to run Identify Local Changes to pick up .xml files added in the course of normal FMOD Studio use while connected to a network, unless that use happened while not connected to your perforce server. Are you regularly using FMOD Studio while disconnected from the network?
The Perforce command for utterly removing a file and all record of the file from a depot is “obliterate.” It cannot be accessed from within FMOD Studio, but can be run from the P4 command line. However, I strongly advise against using this command until you know exactly what the cause of the issue is, as obliteration is permanent.
