Issues with SVN

I’ve upgrade to FMOD 2.0 and added version control (svn) and I’ve run into a problem. When I try and check in any changes I get to following dialog…

Do I need to lock workspace? I would assume FMOD would lock it if needed and I don’t see a way to lock it anyway.

Also, every time I save the project, I get this dialog and it sits here for 20 or 30 seconds. I can see that there is network traffic happening so I assume it’s doing something with the svn server. If every time the project is saved there is going to be this delay, I’m going to suffer a sound designer revolt over version control.

Is this normal?

The slow saving is definitely a bug that shouldn’t happen. We’ve been able to replicate it on our end and will investigate a fix for a future version.

In regards to the locking workspace issue - you might need to alter some settings in the SVN server in regards to locking files. I’ve not been able to see that error message pop up. I’ll do some more investigation and get back to you on this.

I’ve not been able to replicate the locking workspace issue. Are you able to share the SVN server settings so we have similar workspace settings? You can send them to if you worry about privacy.

Does FMOD require the needs-lock setting on all files?

No, our default implementation of SVN does not use the needs-lock setting so you shouldn’t need to use it.

Then I have no idea what’s wrong. My svn repro is hosted on and is completly vanilla. I was using this repro for my FMOD project before enabling svn within FMOD, so at a core level it works fine.

I went to check in my changes outside of FMOD (Versions on the Mac) and I got the following error:

Workspace.xml' is locked in another working copy
'/XXXX/!svn/txr/11-e/trunk/FMODSound/Metadata/Workspace.xml': no lock token available

FMOD is closed and I don’t know of any other “working copy” unless FMOD made one behind the scenes.

This sounds like an issue with the SVN settings. Could you please try doing a clean-up on your FMOD Studio project’s directory and break any locks that might be there?

Doing a clean-up did solve the issues. It’s a little worrisome because I don’t know how it got in that state. Nothing was locked. My sound designers don’t have svn installed, so if this happens to them I’m not sure how to solve it unless FMOD can preform this.

The bigger issue is that from the point I selected sync/merge&commit from within FMOD it took almost two minutes before I was able to enter a commit message and from there an addition 30 seconds until it was done. Performing the same steps in Versions (Mac svn client) is almost instantaneous.

I’m not sure what FMOD is doing during this phase but there is a lot of network traffic. I just changed one sound (didn’t even add new sound data).

Is this normal for version control in FMOD? Just SVN? Or is there something goofy going on.

The only time FMOD Studio locks files is when committing changes, so the two possibilities I can think of is either FMOD Studio had a crash when the commit dialog was active or this was accidentally done some how outside of FMOD Studio.

We are still investigating the SVN project saving issue as it should be just as snappy as if it was offline. When committing changes in a source control project, FMOD Studio will always perform a save and this is where the application seems to be hanging. We can confirm this bug where the project takes a long time to save doesn’t happen with Perforce or TFS so it is certainly something goofy with the SVN integration.

Thanks for the info. I’ll probably hold-off rolling out version control on our project until the bug is fixed. I fear a revolt with those save times. :slight_smile: Do you you have an ETA?

We don’t have an ETA but we are taking a look at it as soon as possible since it’s a pretty big impact on workflow. Thanks for bringing it to our attention.

This issue looks to be a bit deeper and out of our control than first expected.

The problem we are seeing where commands such as saving a local copy are taking a long time are occurring due to a clash between the IP versions of the local SVN application and the SVN server.

If you check out a project using an IPv6 name (eg “svn:/MySVNServer”) but the SVN server is not set up to use IPv6 then it causes multliple commands to be fired off from the local machine’s SVN software to try the same command again using an IPv4 compatible command. To resolve this, you can either make changes on the SVN server, or make changes on how the projects are checked out on your local machine.

If the SVN server is started as a service, enabling the IPv6 option would look like:

C:\Program Files\TortoiseSVN\bin\svnserve.exe --prefer-ipv6 --service -r E:\SVN\Repository

You can relocate an existing local copy of SVN project if the SVN prefers IPv4:

C:\Program Files\TortoiseSVN\bin\svn.exe relocate svn://mysvnserver svn:// E:/MyProject

Since it seems you are using a third party cloud storage solution (Beanstalk App) to store the SVN projects, I would recommend getting in touch with their support or checking the settings in your profile to see if it’s possible to change over to IPv6.

Hi @richard_simms. I’m having this exact problem but I installed my own svn on DigitalOcean. Is there any necessary steps to do to tackle this problem?

We have some documentation that you can look at here: