Audiokinetic's Community Q&A is the forum where users can ask and answer questions within the Wwise and Strata communities. If you would like to get an answer from Audiokinetic's Technical support team, make sure you use the Support Tickets page.

Which wwise file types require exclusive locks?

0 votes
I'm trying to set up Plastic SCM to use exclusive locks for non-mergable file types. It's my understanding that most/all wwise files are not mergable and should be exclusively locked when a developer is working on them.

What are all the wise file types that require exclusive locking? A list of extensions is perfect.
asked Jan 30, 2018 in General Discussion by Eric C. (100 points)

1 Answer

0 votes
.wproj and .wwu extensions are the only project files aside from the .wav sources which need version control.  All other file types may be recreated by an audio build from Wwise.

.wav files are binary and therefore not mergable in the textual sense.  .wproj and .wwu files are xml and therefore possible to merge in most cases.  It really depends on the user operations that occurred in the change.  Typically a resolve/merge conflict will only arise if two users editing the same workunit perform incompatible changes, for example if user A sets a mix volume on a sound that user B has deleted in their change.  If user A and user B are just adjusting existing settings that don't overlap, their changes may be merged without conflict.

IMO, If you set the .wproj or .wwu files as exclusive check-out, then you are going to create more difficulty for a team using Wwise than you will solve.  Certain regular operations for a few specific files require simultaneous check out and merge or it will prevent other team members from accomplishing tasks while they wait on file locks to clear and then re-sync and reload the Wwise project.

For example, user A and user B both want to create a new workunit in the root of the Actor-Mixer Hierarchy. In order for their workunits to be added, the .wproj file must be checked out and edited by each user.  The change to add a reference to each new workunit in the .wproj file is usually mergable with no conflict.  However if under exclusive lock scenerio after user A has the .wproj file open and locked, user B will not be able to save their work or proceed until User A checks in and User B syncs and reloads the project at which time some of their work may be lost if they didn't get to save yet.

Second example, for the Master-Mixer Hierarchy if both users are attempting to mix or edit effects of different busses in the heirarchy, they will both need to be able to check out the Default Workunit there in order to work independently at the same time, because this is the only workunit that loads into wwise.

For all other workunits  - they exist as a means to split up work so a team can collaborate without getting in each other's way.  Adding more workunits according to the organization of assets in the project helps reduce cases where merges are required from users working simultaneously in the same .wwu files.

Coordination among the team using Wwise is necessary for them to avoid non-mergeable operations to the .wwu files but it is better than being locked out of accomplishing any work.
answered Feb 12, 2018 by Jason C. (150 points)