Unity workflow with SVN for small teams

In this post we are going to highlight what needs to be committed to SVN and also about the workflow of a small team (5-6) people using Unity (free).

If you want to have a better understanding of what Unity is doing underneath you might want to have a look at the links found at the end of this post.

Let’s start with a new project.

1. Create a new project
2. Create a prefab
3. Create a cube
4. Drag cube into new prefab
5. Create a material
6. Import a texture
7. Assign the texture to the material
8. Assign the material to the prefab
9. Save scene
10. Quit

In your scene you should have a camera and a prefab instance.

Let’s try removing some files, and try relaunching Unity afterwords. Before launching Unity, create a copy of the trimmed project. You’ll soon know why.
In the project folder (if you launched Menodevelop) delete the following:

• Temp
• *.csproj
• *.pidb
• *.sln
• *.userprefs

In Library folder you need to delete the following (DON’T DELETE METADATA!!!)

• cache
• previews
• ScriptAssemblies
• assetDatabase3
• AssetImportState
• AssetServerCacheV3
• AssetVersioning.db
• AudioManager.asset
• BuildPlayer.prefs
• BuildSettings.asset
• DynamicsManager.asset
• EditorSettings.asset
• EditorUserBuildSettings.asset
• expandedItems
• FailedAssetImports.txt
• guidmapper
• InspectorExpandedItems.asset
• MonoManager.asset
• NetworkManager.asset
• ScriptMapper

DON’T DELETE METADATA!!!
The files in Library should look something like this

After launching Unity, you should see that it’s re-importing and compiling everything. The textures and prefabs should appear fine in your scene.

If it loaded fine then you can import the trimmed version (the copy you had made) into your SVN repo. I would upload it in a folder called unity, so you can have other folders for art (like PSDs, 3dsmax files etc) and docs separate from the unity project.
Once it’s imported, delete your project since it is not associated with SVN yet. Do a checkout of the project folder. Launch Unity and open the SVN project. You should see it reimporting everything and you should get everything as it originally was.

The main idea is that we don’t commit anything which can be automatically generated by Unity. This will also eliminate a lot of useless conflicts. We can set up an ignore list so that the SVN client doesn’t bother us with.
To the ignore list add the files that you had deleted and that now have reappeared because of Unity’s recompilation process

Here are some commandments the team should follow:

1. thou shalt not modify the same asset (scene/prefab/material/texture). Do this by doing an SVN lock on any binary file BEFORE doing any changes.
2. thou shalt not forget to add any new assets and related metadata to the repository
3. thou shalt not forget to remove any deleted assets and related orphaned metadata folders. Keep SVN repo clean
4. thou shalt close Unity before doing any SVN operations
5. thou shalt do an update before committing
6. thou shalt run the leanAndMean batch file after an update
7. thou shalt not save the scene, if you actually didn’t modify the scene’s hierarchy or instance values in some way (avoids useless commits)

The 1st commandment is the toughest. Try to communicate between you who is modifying what. If you are working on some tasks which will finally end up in one scene, you might want to create a temp scene for each individual, sort of prototype scenes. Then the leader should merge all the assets in the main final scene. This could be done by dragging of prefabs, or importing unity packages in the main scene. Also locking will help (see below)
To keep it from getting messy, only programmers should interact with SVN. For the artists you could have a separate folder, or only give them instructions to upload directly in Assets/Sounds or Assets/Textures folders. But PSDs should not be part of Assets as it would take much more time when Unity is rebuilding the Library files after you run the clean batch file.
If the artists in the team are not technical and you think that SVN is going to drive them nuts, then set up some shared Dropbox folder and the leader would need to commit any art done by the artists.

Be diligent when committing and add any assets you’ve created, and any new metadata files/folders in the Library/metadata. Also when delete a file which is not part of your game anymore, delete files through SVN, relaunch Unity and their related metadata will automatically deleted. Keep SVN clean.

When you delete assets, their related metadata is removed but their associated folder will not be removed. You can safely SVN delete empty folders in the metadata folder.

After doing an update, you should get the Library folder lean and mean again. The easiest way will be by doing a script or batch file.
Here’s one for Macs. Call it leanAndMean.sh and place it in your Library folder:

rm assetDatabase3
rm AssetImportState
rm assetservercachev3
rm AssetServerCacheV3
rm AssetVersioning.db
rm AudioManager.asset
rm BuildPlayer.prefs
rm BuildSettings.asset
rm DynamicsManager.asset
rm EditorSettings.asset
rm EditorUserBuildSettings.asset
rm expandedItems
rm FailedAssetImports.txt
rm guidmapper
rm InspectorExpandedItems.asset
rm MonoManager.asset
rm NetworkManager.asset
rm ScriptMapper
rm -r -d -f cache
rm -r -d -f previews
rm -r -d -f ScriptAssemblies

Remember to do chmod 777 leanAndMean.sh in some terminal window.
For Windows the leanAndMean.bat will look something like this:

del assetDatabase3
del AssetImportState
del assetservercachev3
del AssetServerCacheV3
del AssetVersioning.db
del AudioManager.asset
del BuildPlayer.prefs
del BuildSettings.asset
del DynamicsManager.asset
del EditorSettings.asset
del EditorUserBuildSettings.asset
del expandedItems
del FailedAssetImports.txt
del guidmapper
del InspectorExpandedItems.asset
del MonoManager.asset
del NetworkManager.asset
del ScriptMapper
rmdir /s cache /q
rmdir /s previews /q
rmdir /s ScriptAssemblies /q

Also don’t forget to add it to your SVN repo on your next commit

What happens if you forget to run this batch file?

Let’s say you create a new material with a new texture and associate with a prefab, and you commit. The other guys after doing an update would see a pink color instead of your texture.
Running the batch file/script will solve this issue.

Even if you are going to try your very best to avoid people working on the same assets, it will inevitably happen at some point in time. Let’s think of a scenario.
If A modifies a scene (e.g. a value of a script within a prefab instance) and commits, AND B modifies the same scene, and tries to do an update he will get a conflict. Since it’s binary it will not be merged automatically. You will have 3 files, e.g:
• scene.unity
• scene.unity.r3
• scene.unity.r5
These are basically your current version and the previous 2 remote versions.
Since it’s not text, it cannot merge it. You will have to decide which is the best version by inspecting them in Unity. So you will have to play around by opening the different versions. For the case of scenes, perhaps renaming them to scene_r3.unity and scene_r5.unity might help to open them quickly within Unity.
Once you merge them manually, delete the remote versions (r3, and r5 in this case), mark your scene file as merged, and commit.
Prefab conflicts will be similar. Let’s say you have your version called test.prefab, and the last two remote versions, test.prefab.r5 and test.prefab.r7. You have to manually decide which is the best one or merge manually by inspecting the values within unity and creating the merged prefab.

So far we didn’t mention anything about locking a file. What we covered so far is Copy-Modify-Merge flow (update, do the changes, commit and hope no one touched the file).
A better workflow would be for binary files such as scenes, textures, material, prefabs (but not scripts as they are just text files and easily mergeable), we should use the Lock-Modify-Unlock approach (lock, do the changes, commit and should automatically unlock the resource).
So if person A wants to modify test.prefab, he first should do an SVN lock on the file. While he is doing the changes, if person B wants to also modify the test.prefab he needs to first try to obtain the lock. If the file is still locked by A then SVN will warn B that someone else has the lock and so shouldn't modify until A commits and releases the lock.

So lock, do any changes, commit. If the lock fails don't do any changes. Needs some diligence but this will avoid any conflicts.

http://bitflipgames.com/2010/09/13/tips-for-working-with-unity-1-source-control/
http://answers.unity3d.com/questions/22604/which-unity-project-files-can-be-ignored-for-versi.html
http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html

(来自：http://gamedev.stmartins.edu/2011/07/unity-workflow-with-svn-for-small-teams/)