How do I manage large art assets appropriately in DVCS?

Thoughts, no experience: I would indeed seperate code from data. Assuming that there is a set of images that belongs to the application, I would just keep that on a centralized server. In the code, I would then arrange (through explicit coding) that the application can integrate both local or remote assets. People contributing can then put new images in their local store at first, integrating it with some kind of (explicit) upload procedure into the central store when required and approved.

These are some thoughts I've had on this matter of subject. In the end you may need to keep assets and code as separate as possible. I can think of several possible strategies:

Distributed, Two Repositories

Assets in one repo and code in the other.

Advantages

• In web development context you won't need to clone the giant assets repository if you're not working directly with the graphic files. This is possible if you have a web server that handles assets separate from dynamic content (PHP, ASP.NET, RoR, etc.) and is syncing with the asset repo.

Disadvantages

• DVCS tools don't keep track of other repositories than their own so there isn't any direct BOM (Bill of Materials) support, i.e. there is no clear cut way to tell when both repositories are in sync. (I guess this is what git-submodule or repo is for).

  Example: artist adds a new picture in one repository and programmer adds function to use the picture, however when someone has to backtrack versions they are forced to somehow keep track of these changes on their own.

• Asset repository overhead even though it only affects those who do use it.

Distributed, One Repository

Assets and code reside in the same repository but they are in two separate directories.

Advantages

• Versioning of code and assets are interwoven so BOM is practical. Backtracking is possible without much trouble.

Disadvantages

• Since distributed version control tools keep track of the whole project structure there is usually no way to just check out one directory.
• You still have the problem with repository overhead. Even more so, you need to check out the assets as well as the code.

Both strategies listed above still have the disadvantage of having a large overhead since you need to clone the large asset repository. One solution to this problem is a variant of the first strategy above, two repositories; keep the code in the distributed VCS repo and the assets in a centralized VCS repo (such as SVN, Alienbrain, etc).

Considering how most graphic designers work with binary files there is usually no need to branch unless it is really necessary (new features requiring lots of assets that isn't needed until much later). The disadvantage is that you will need to find a way to back up the central repository. Hence a third strategy:

Off-Repository Assets (or Assets in CMS instead)

Code in repository as usual and assets are not in repository. Assets should be put in some kind of content/media/asset management system instead or at least is on a folder that is regularly backed up. This assumes that there is very little need to back-track versions with graphics. If there is a need for back-tracking then graphic changes are negligible.

Advantages

• Does not bloat the code repository (helpful for e.g. git as it frequently does file checking)
• Enables flexible handling of assets such as deployment of assets to servers dedicated for just assets
• If on CMS with a API, assets should be relatively easy to handle in code

Disadvantages

• No BOM support
• No easy extensive version back-tracking support, this depends on the backup strategy for your assets