So, you’ve bought Unity Pro and the Unity Asset server. If you’re like me, in spite of its disadvantages, you really like the UAS. It’s integrated into the editor and does a much cleaner job of versioning on serialized assets than does external version control, because it operates on the project’s Library folder rather than requiring you to generate and synchronize all of the sidecar data. However, there are some key things it cannot do.
I don’t have very complicated needs like branching and so on, but I do have a library of common code that I share across projects. This library contains a bunch of useful stuff that doesn’t rely on any game systems: things like helper classes, math classes, serialization for built-in types, and so on. The trouble is, I’m often working simultaneously on a bunch of projects that share my library (or worse still parts of my library), and so it can be a pain in the neck to push the changes out across all my projects. As such, I took the time to set up a system using Subversion working on top of my UAS projects in order to synchronize my library code.
Apart from Unity, you obviously need Subversion. If you’re on OS X, this is part of Snow Leopard, so you’re good to go. Because I’m not especially adept at all the setup, and because there are plenty of really good tutorials, I won’t go through all the details. Basically, you need to prepare a repository somewhere and get a good SVN client. If you’re on OS X, I really recommend Cornerstone. It’s not open source, but it does some key things I need:
- It has a great GUI. Apart from letting you do things easily, it also allows you to set up each working copy to show when it is out of sync, so I know which Unity projects needs to pull down new library updates.
- The GUI lets you effortlessly modify your snvignore settings, allowing you to exclude all of your non-library code from your SVN repo. For example, I only want to include folders like Assets/ Scripts/Library, and Assets/Editor/Library, so I want to be able to easily exclude my per-project code and assets from the SVN repo.
- It lets me take advantage of sparse checkout features in SVN. This feature was actually the deciding factor for me, as I distribute packages in the Unity Asset Store with limited copies of my library code. For example, my Biped Editor package contains library code for my VectorHelpers class, but not FloatMatrix. This requirement was also part of the reason I opted for SVN instead of Git. Maybe it’s possible to manage it easily with Git, but it wasn’t something I was up for fighting against!
The basic requirement to make this work as painlessly as possible is to have parallel structure in your Unity projects. I have a generally parallel structure, but because of Asset Store requirements, for example, my library code needs to be in folders like Assets/PackageName/ Scripts/Library, whereas all of my games are simply Assets/ Scripts/Library. Because of this issue, instead of making my Assets folder top-level in my repo, the repo simply has Scripts/Library, Editor/Library, and Plugins/Library at the top level. The problem in the video, as you can see, is that all of my working copies for my games are called Assets, whereas having Assets as the top-level folder in my repo would allow Cornerstone to display my Unity project folder names in the working copy list, so I wouldn’t have to look in the inspector to double-check what project I’m in. Depending on your SVN client, you may or may not experience this problem. Probably the absolute easiest way to set your project up is to have an Assets/Library and an Assets/Game folder in your project, the latter of which contains all of your actual per-game stuff. Using this organization, you would only have to apply svnignore to the Assets/Game folder in your working copy, instead of having to add all of your individual project folders. I leave it up to you to know what is best for your needs, but it suffices to say “stop and think about it before you pull the trigger.” Once you’ve picked out your organization system, export your library code as a unitypackage from Unity’s main menu.
At this point, create a new, empty Unity project and make it a working copy of your new SVN repo. In my case, I had to point to my project folder and call the working copy Assets because of my organizational structure. Again, if your repo will contain Assets, your project folder can be your working copy folder, but you’ve probably already figured that out.
Now, import your unitypackage into this empty project using the one you just created. This will populate your project with your library code.
Finally, check your library into the repo and voila! Now you have a common code library under version control sitting on top of your Unity project, which is managed using the Asset Server.
Now, if you set up a new project, just always make it a working copy of your repo first thing. If you dump all of your game assets into a folder that is already ignored (e.g., Assets/Game), then you shouldn’t have further work to do. Otherwise, make sure you remember to ignore your non-library folders when you commit any library code changes to your SVN repo. Using a client like Cornerstone, any new folders will show up in bold in your working copy view, and you can easily ignore them from the inspector or using the RMB context menu.
If you want to get extant projects set up on your SVN repo, you may want to first rename your extant project folders whose names conflict with those on the repo. You can then make your project a working copy and move over anything from your renamed folders that you need to keep and ignore or commit to the repo.
I hope some of you find this helpful, but if not at least I’ve documented it for myself!