Search Unity

  1. Unity 2020.1 has been released.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Source Control of Unity Packages

Discussion in 'External Tools' started by fatso, Jul 29, 2006.

  1. fatso


    Jul 21, 2006
    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, 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).
  2. fhmiv


    Jan 31, 2007

    This sounds like an interesting approach. How is it working out for you?

  3. NCarter


    Sep 3, 2005
    I'm not sure what you'd do about conflicts caused by two people trying to check in changes to the same files. It's bad enough sorting out a complex conflict in ordinary source files, without the extra difficulty of having to deal with large numbers of automatically generated files with mysterious names and purposes.