The last thing I’m really struggling with in terms of adopting Unity as an engine is source control; I just can’t see professional development working without a reasonable strategy in place. I had some rambling thoughts in this thread http://forum.unity3d.com/viewtopic.php?t=2361, but after further experimentation, I have a simpler approach to propose:
The official recommendation for source control is using package import and export to version and exchange complete collections of assets. I’ve previously stated that this seems crude because of the limited ability to version individual assets, and the hugh amount of storage space required because of binary deltas won’t work well on the unityPackage files.
Well, it turns out that unityPackage files are just gzipped tar files. Inside, the assets are maintained as a flat collection of records, organized by ID, with path information stored in parallel. So if you just explode the archive, the resultant tree is quite suitable for checking into a version control system (such as subversion). Because the package is organized by IDs, it doesn’t even require a complex svn mv strategy to track asset history across rearrangements, you will be able to see the move history via the log of the path files. This allows multiple people to work on the same package of assets at one time and merge the results (although you’d probably still want to subdivide any large project into multiple packages).
This approach would benefit from automating the process of adding a set of asset packages into a base project, which you should be able to do via AppleScript. Then you could have a project file which listed all the packages to include (say, as a list of svn paths, similar to the way svn externals work). This might even move towards reasonable build reproducibility.
Can anyone see anything wrong with this approach? One concern I had was maintaining links between assets in different packages – but Unity seem to do this rather well (I never seen reimporting packages break links).