Salman Abdollahi's List: Game Asset Version Control

• Subversion is a good choice for working  with frequently edited binary files, due to its centralised  nature and support for file locking.
• Mercurial is bundled with an extension named convert, which can incrementally  import revision history from several other revision control  tools.
• In addition, convert can  export changes from Mercurial to Subversion. This makes it  possible to try Subversion and Mercurial in parallel before  committing to a switchover, without risking the loss of any  work.

1 more annotation...

• Which files to manage, and which to avoid
• centralized systems often  provide a file locking mechanism that allow a user to say  “I am the only person who can edit this  file”
• a distributed revision control system cannot,  by its nature, offer a file locking facility.
• If you have a team where several  people may be editing binary files frequently, it may not be a  good idea to use Mercurial—or any other distributed  revision control system—to manage those files.
• When storing modifications to a file, Mercurial usually  saves only the differences between the previous and current  versions of the file. For most text files, this is extremely  efficient. However, some files (particularly binary files) are  laid out in such a way that even a small change to a file's  logical content results in many or most of the bytes inside the  file changing.
• This can  affect both local storage needs and the amount of time it takes  to clone a repository.

4 more annotations...

• What are the issues using VCS, with regard to non-text files (binary files), large projects, etc? What are solutions to these problems, if any?
• Mercurial

• With regard to the use of non-text files, last versions of Mercurial (>=2.0) provide the largefile extension by default:

    

   

  largefiles solves this problem by adding a centralized client-server  layer on top of Mercurial: largefiles live in a central store out on  the network somewhere, and you only fetch the ones that you need when  you need them.
• The Python project is a large project and uses Mercurial.
• Git is good and all but when it comes to handling big graphic or music assets, such as larger than 100's of MB, it becomes noticably slow at commits and check-outs. At the moment Mercurial, the contender to Git, has a "big files" extension that addresses this specific issue.
• Why not use Git's submodules to manage the binary files? That way you could create separate repositories as needed and then tie them together using submodules. Any future changes in the main repository should not affect the submodules.
• Perforce
• It's a commercial product
• You can see who is working on what. Games have an abnormally high number of rapidly changing binary files (assets) compared to other development projects. Most of the time these are non-mergeable, so keeping track of who has what/where/when is critical. Subversion and DSCC clients intentionally avoid this technique, but it's quite beneficial in certain applications.
• AlienBrain

• Alienbrain is a digital asset  management system for artists in the  entertainment industry

   

    
   
  • Commercial (more expensive than Perforce), centralized
   
  • Designed to integrate with other professional 2D and 3D workflow tools such Photoshop, Maya, 3ds Max, Microsoft Visual Studio, etc.
• For those of you with really serious  asset tracking problems and equally  serious budgets...
• My experience with AlienBrain is that the authors do not get game development. It is not a robust source control solution. Some of the features are nice for some of the team, but some of the coolest advertised features aren't implemented in such a way as to be useful (e.g. the staging interface, where someone can check in their assets "for review." Unfortunately there's no way to know what is for review and what isn't, and when you sync you get it anyway). Plus it caches nothing, so a sync requires testing every single file. This is slow with many gigs of assets.

11 more annotations...

• you absolutely should have assets in the same repository as your source.
• You want your version control to behave like version control. You want to be able to rewind and fast-forward and branch and merge revisions and still have your game working. And your code and assets will depend on each other.
• you don't want or need all the "in progress" versions of your assets under version control! Just the final/working version, as used by your code, will do - often this is what you export from your tool.
• (Although if you do want to version-control the in-progress versions of assets - that's fine. And well suited to a separate repository. I personally find that good folder organisation and a proper backup system suffices.)
• Keep the assets in a separate repository from the source, to make it easier to keep checkout / sync times to a minimum and take different decisions on how much history to retain
• Mark XML files as binary, merge tools tend to be very bad at merging nested markup and artists aren't likely to spot broken markup if the tool thinks there are no conflicts.
• arrange a syntax check or even asset build on every commit and reject the commit with an email back to the person committing if it fails; this will save a great deal of team time.
• Everything in one repository,
• Also, artists much check in everything, including the 30 rough outlines of a concept; we use separate folder trees for "source assets" and for "exported" - the ones that go into the asset build script.

7 more annotations...

• Mercurial has various extensions to deal with large files, especially binary ones.

    

  Since version 2.0, the Large File extension is included in Mercurial and you can use it without downloading anything else. Files are not directly stored in the repository, but Mercurial tracks which version of the file is needed for each changeset, so you can download a precise version of your game with the right file when you need them.

• As mentioned in an answer to this question, you can use the convert extension to create a new repository. Use --filemap to exclude the large files you don't want.