I wrote about this earlier, but I need to re-open the topic; I need help with this:
The following happens only when I have Perforce version control on. When I change the version-control setting to ‘none’, the problem seems to stop. But sometimes, I can delete an event, hit save, close Studio, re-open Studio, and the events are back. Could it be grabbing the old versions off the P4 server when I choose ‘Sync latest, merge, and commit’ ? If so, what would be the best solution? I’m thinking of making a backup, using P4V to delete the whole project on the P4 server and then just re-submitting my local project files as if they were new…
I have tried deleting the .cache folder: no effect.
Suspiciously, the number of metadata files placed in the P4 changelist if often less than the number of events I have deleted.
I am not using the Perforce interface to open or submit these files. (Although I have done that in the past on this project)
The behavior is identical from Studio 2.01.06 and 2.01.09.
The behavior is identical on my Windows10 PC and my Mac laptop.
Under normal circumstances, FMOD Studio will only get an event from the repository when you sync latest, merge and commit if the event was added or changed in a more recent changelist than what you have locally. As such, unless the deleted events were edited on a different machine since the last time you got a local copy, selecting “sync latest, merge & commit” should not cause your local machine to download a new copy from your repository.
If you select “Sync latest, merge, and commit” after deleting an event, the deletion should be submitted to the server, and other users or machines should see those events disappear the next time they select “sync latest, merge, and commit” themselves.
To clarify, are you selecting “Sync latest, merge, and commit” after deleting the files? It is necessary to do this in order to send the delete change to your perforce repository.
That is definitely suspicious. Each event has a corresponding metadata file, and deleting an event should result in deleting the corresponding metadata file.
Is it possible that some of the deletions have been placed on hold instead of submitted? That could Next time you synchronize, merge & commit changes, check whether there’s anything in the submit dialog’s “On Hold” tab. If there is, try moving it back to the “Submit” tab, as it may be the culprit.
To clarify, are the same events reappearing on both machines? Or does each machine resurrect a different set of events? I ask because if it’s the same files the issue is likely in the depot, whereas if it’s different files on each machine, it’s more likely that the issue is local to each of them.
Ah, I’m glad to hear you were able to resolve the issue. I’ll make note of the steps you took to fix the problem just in case someone else runs into this issue, and will continue trying to determine the cause.
Sure, thanks. I lack the expertise to fully understand the cause, but in layman’s terms:
It seems that by submitting metadata files directly in the P4V interface instead of the Studio interface, it caused files to exist in the P4 depot which I did not want to exist in the project, and/or older states of extant files to remain in the P4 depot which I tried to supersede, and then every time I opened Studio, those depot files would re-assert themselves into my project. (e.g. I would delete an event only to see it return upon re-opening Studio)
I imagine that would be because when one submits metadata files via the P4V interface, it prevents Studio from doing certain housekeeping tasks? Something like that.
I updated the solution steps above to include disabling version control as a first step.
Dang… Unfortunately the problem returned fairly quickly after having been eliminated. This time I am certain I was not submitting metadata via P4V, nor do I have the .cache or .user folders in the depot.
The bottom line seems to be: Studio is sometimes unable to remove metadata files from the Perforce Depot, even though it does remove them from the local drive. It is not clear to me whether that is a Perforce problem or a Studio problem.
Details:
I am seeing the re-appearance of events I have deleted, and when I delete them again, no new files are marked as changed in P4, and when I sync-merge-submit, Studio reports “no pending changes”. I have observed exactly what is happening:
I delete something in Studio. Example: A parameter.
I submit that change through Studio. (sync-merge-submit)
I close Studio.
I verify that the corresponding metadata file has been removed from my hard disc.
I verify that it has NOT been removed from the depot.
I re-start Studio.
During loading of the project, the file which had been previously deleted is brought back down from the depot onto my local drive, and so the deleted parameter re-appears in Studio.
I delete the parameter again.
Sync-merge-submit again.
Studio flashes notifications that it is reverting things, and then says ‘no changes’, and does nothing.
The file is still on the default changelist in P4, with a check, not an ‘x’.
The file does not exist on my local drive, despite being in the changelist. Attempting to submit through P4 produces a “The system cannot find the file specified.” error.
I revert the bogus files from the P4 changelist, and they are re-obtained from the depot.
However, then when I delete them directly from the depot, instead of via my local drive, this deletion seems to be permanent. But now I’m bypassing Studio’s version control, which as we’ve discussed can cause additional problems.
I don’t see how this could matter, but is it a problem that I have the .fspro file in the depot?
What are some other things which could cause this, and how can I avoid it?
Unfortunately, I have still not been able to reproduce this issue. When I test here, deleted items stay deleted. I must be doing something differently to you, but without knowing what, it’s impossible for me to determine the cause of this issue.
When you load the project in step 7, are you selecting “File > Open…” or “File > Source Control > Browse For Project…?” I ask because the latter should only be used to generate a a new local copy of a project from your source control repository if you do not already have a local copy of the project on your hard drive, which might explain why loading the project is making changes to your local copy.
If a local copy subject to source control already exists on your hard drive (as it does in your case) you should instead load the project via “File > Open…” This command does not get or synchronize your project with the repository; it merely opens the local copy of your project, allowing you to continue working on it as usual, while preserving your project’s source control settings so that you can choose to submit changes when and if you wish.
To help us narrow this down, does the issue occur if you create an entirely new FMOD Studio project and an entirely new perforce repository?
No, this is definitely not a problem. In fact, if that file was missing from your depot, you would encounter serious problems. An .fspro file is necessary for a project to function.
An .fspro file is necessary for a project to function.
I mean as opposed to keeping it out of the depot, like the .cache folder, for example.
Re: Sync issues, I’m surprised I am the only user who has ever reported anything like this… I would have thought there would have already been a fairly large body of wisdom about how to avoid messing up your project.
are you selecting “File > Open…”
I usually just select my project from the short list of recently-opened projects Studio displays upon launch. I am aware of the ‘Browse For Project’ feature, but have not had occasion to use it.
To help us narrow this down, does the issue occur if you create an entirely new FMOD Studio project and an entirely new perforce repository?
I did sort of do that when I backed it up and then introduced it to P4 as a new thing, but clearly that isn’t exactly the same. I can try that, although it could take some time for the issue to show up, as I do not know precisely what triggers it.
Those commands function the same way as “File > Open…” This is an important clue, because “File > Open…” doesn’t check the Perforce repository; it just loads the local copy of the project that’s on your hard drive.
If deleted events are appearing when you load the project, this means that their .xml files are still present on your hard drive before Studio is launched; if they were absent, then the deleted events wouldn’t appear in FMOD Studio’s browsers. Either they’re somehow being automatically restored to their former places while Studio is closed, or they’re never being deleted from your hard drive in the first place.
I’m confused as to how this is possible, though, given that you’ve said the files are definitely missing from your drive. What tools are you using to verify their absence? P4V? Explorer? Finder?
If deleted events are appearing when you load the project, this means that their .xml files are still present on your hard drive before Studio is launched ;
Maybe, but I have put P4V and Studio up side-by-side and watched it happen. The file popped onto my hard disc directly after loading the project, but after starting Studio. It was as though Studio was asking the depot to send it anything it was missing.
What tools are you using to verify their absence? P4V? Explorer? Finder?
Mostly P4V, but my file browser too. However, it has been more common that the opposite is true: Studio puts .xml files representing the phantom objects in the P4V changelist which do not exist on my drive. When I was still submitting them through P4V, it would say that the files can’t be found, and sure enough, I looked and they were not on my drive. They were in the P4 depot, though, and when I manually delete them there, within P4V, that seems to resolve the problem permanently. Now that I do it via Studio, In those cases, when I delete them (again), sync/merge/commit in Studio produces a “no changes” message in Studio.
I wonder if something it getting messed up when P4V closes, opens, or crashes (a daily occurrence) while Studio is running?
I do not know why this is happening. As far as I am aware, FMOD Studio only gets files from the server if you select a source control command that does so. It should not be downloading files when you load the project; and indeed, when I test it here, it does not.
FMOD Studio does not directly interact with P4V. Rather, it interacts with P4. So, in theory, P4V crashing shouldn’t directly affect FMOD Studio.
That being said, it could theoretically affect it indirectly. If P4V crashes mid-way though a Perforce operation, it could theoretically leave the depot or local workspace in a bad state.
However, given that you’re no longer using P4V to manage your FMOD Studio project, it is unlikely that such a bad state would include the files in your FMOD Studio project unless the issue was caused before you stopped using P4V to handle your FMOD Studio project.
