Should I keep binary assets under TFS? How?

Question

Our product is game-like, and is very rich (~40M - 100M) in binary supporting files - textures, meshes, movies etc. Like kai1968, I'd like to be able to sync-in these assets, and not just code, with a single click.

Strictly speaking, however, that is different than version control: I have no desire to burden our TFS with irrelevant history of these files. Can I somehow upload stuff without keeping history to TFS? It would be even better if I could opt to keep history at specific points (say, label points), and not in every checkin.

More generally, how do you manage sync of binary assets?

(I'm aware of other tools, perhaps better suited for such tasks, but diverging - or altogether migrating - from TFS is not an option right now.)

Answer 1

We've always kept binary assets in TFS when we need to, and just dealt with the side-effects of that choice (extra storage, longer check-ins because you can't diff on binaries, etc). I don't believe there's a way to selectively destroy the history of certain files, except manually. If you want to do this periodically, by hand, you could do the following:

1. Get a curent copy of the binary files
2. Destroy (delete with history) the binary copies in TFS
3. Manually add the files back to TFS

You'd have only the most recent copy, but this has a side-effect - you'd break any previous builds, since an attempt to retrieve source history wouldn't return these new copies of the files. TFS would check for a copy that matches the checkout you're attempting, and finding none, it wouldn't retrieve a copy of those files. You'd need to update your build scripts to pull the most recent binaries, as well as the historical code, if you wanted to build an old version, but even then, it won't be a true history.

The second option is to only check them in periodically - not with every single minor change. For example, keep these files somewhere safe (a file share with daily backups), and then only check in the changed binaries every week or so, or before every label, or whatever - this way, you don't have incremental history, but you'd still have your label history. You might even consider writing some kind of automated routine to apply labels, where it would check in any changes in that folder first, then apply the label.

Please post back what you end up doing - I'm curious to know!

Answer 2

The following doesn't help me personally - as we're using VS2005 - but I thought I'd post it in case it helps anyone else:

There's a VS2008 addin that seems to nicely address this issue, and more. Does anyone have experience with it?

Answer 3

Here are a few thoughts:

• Consider using a separate VSTS project, so you don't mix the binaries and code in the same project. This makes it a bit easier to manage (e.g. you can keep the assets separate, and also any work items relating to them are more easily queried by filtering on the project). On the down side, this would mean 2 clicks to get latest.

• Why don't you want to keep histories? The point of source control is to keep history so you can go back to a particular build for a particular day. Otherwise, you might as well just use a backup program on a network drive (and you really don't want to do that!)

• If you're only worried about disk space usage, then don't. 100MB is tiny, and hard drives are cheap. My last game project had hundreds of gigabytes of assets and we kept the history of every change for over 3 years.

• The assets won't slow anything down. They only take time to process if you check them in or Get them, which are both activities you will need to do even if you don't use source control. Indeed, source control makes things faster because you have a "one click does it all" solution.

• The many other benefits of source control are really useful on assets, and vastly outweigh the negatives.