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:

1. 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.
2. 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.
3. 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!

1. Use sys.path.append() in your userSetup.py file
2. Set the value for PYTHONPATH in your maya.env file
3. Set the value for PYTHONPATH at the system level

Autodesk’s documentation can help you figure out the first two methods reasonably well, and they work fine for most situations. However, if you have locations you want to use with Maya as well as other interpreters, the third option may be helpful. While doing this on Windows is relatively easy, it is a little painful on Mac OSX.

Most Google searching will send you to some variation on this technique, whereby you create an environment.plist file containing the value for your PYTHONPATH variable and place it in a folder ~/.MacOSX. Maybe this will work for you, but maybe it won’t. It didn’t work for me. What’s the problem?

Apparently, when you start an application from Spotlight as opposed to Finder, it has a different parent process—one that does not use the environment.plist file. I have gotten used to using Spotlight to start all of my applications and to perform the majority of my menu operations because it saves me huge amounts of time while working (and I don’t want to have to remember where stuff is). Fortunately, there is a fix that will ensure your environment variables will be properly set in all contexts. I suggest you read about the details if you are interested, but if you just want to work then use the following solution:

1. If you do not have a launchd.conf file in /etc then create one
2. Edit launchd.conf to contain a line like this: setenv PYTHONPATH /Users/Shared/Autodesk/maya/scripts
3. Reboot

You can now confirm that this has worked by opening Terminal from Spotlight and entering the set command.