Re: [GD-General] Re: asset & document management

[Neil S. <ne...@r0...>]

> How does it handle an artist that creates 182 versions of a 80 megabyte
> binary file in the course of 3 weeks? I suppose CVS would end up with 14
GB
> of archives, by which time it has probably long croaked :-)

Well, it doesn't do binary diffs, which means it would have to store a
complete copy of every version of the file (i.e. 14GB, same as CVS). It can,
however, do a basic binary compare so you can avoid storing multiple copies
of the same file. In my experience, artists tend to check out an entire
directory, change one or two files, and then check them all in again, so
this simple compare can save a lot of space. The only downside is that it
only seems to do the compare when you ask it to "revert unchanged files",
not when simply checking in the files, so it's a bit of a pain if people
forget to do that (also quite common).

One ray of light, though, is that it will use a user-provided diff utility,
so you could try giving it a binary-aware diff utility. What I'm not sure
about is whether it will handle the output from a binary diff or not. I was
planning to look into this at some point, so if I ever get round to it, I'll
let you know what I find out.

> I've looked at Perforce in the past, it's a really nice product, simliar
to
> what we already know. But does it handle really, really large amounts of
data?

Contrary to what I've said above, it actually does handle a lot of data
rather well, albeit in a brute-force manner and using a lot of hard disk
space. With a huge amount of data, it does start to slow a little, but not
nearly as badly as you would expect. We split our code and data into
seperate depots, just to maintain a certain level of slickness in the code
depot, but we do have a lot of data, and this wouldn't be necessary for all
projects.

On top of this, Perforce is extremely reliable, almost supernaturally so,
which is a major factor when looking after your most important assets. ;)

- Neil.