Large Binary Files

[Chris Hecker]

I'm writing a post on my website about this, but I'm a) too swamped to 
write it for another couple months, and b) waiting until I have more bzr 
experience, but, the following points seem to be the case right now with 
bzr/hg/git:

1.  There are no partial checkouts, so if you set up your tree like most 
games, where there is source_content (mb files, psds, etc.) and content 
(your model formats, dds, mp3, etc.), you can't have 
programmers/non-artists only sync to content and ignore source_content.

2.  There is no way to store a subset of the history locally, so you 
will have every version of each large binary file.  With p4, this 
obviously happens on the server, but hey, it's a server with 10TB of 
RAID storage or whatever.  With svn, you get 2x due to the working copy 
format, which sucks, but it's bounded.  With dvcs, you get all the 
revisions, basically full size for each one.  HG copies the file in the 
repo on renames as well, currently.

3.  There is no way to lock a binary non-mergable file, because there is 
no central repository.  So, you could easily have two artists edit the 
same mb or psd and then have to resolve the problem manually themselves.

4.  There are several hacks for hg that attempt to store files that 
point to other files outside the respository, but this seems busted and 
fragile to me.

I'm sure there's more, that's off the top of my head.

Chris



On 2010/10/13 16:58, Kip Warner wrote:
> Hey list,
>
> I am working on a fairly large free, commercial, game
> (https://www.avaneya.com). I am seriously considering getting off the
> Subversion bandwagon and using Bazaar for the project, though sticking
> to the cathedral centralized model.
>
> One of my concerns is how Bazaar handles large binary files. This is
> common in games where we have things like cinematics and other large
> files where compression and computing revision deltas doesn't always
> work very well.
>
> What should I know about how Bazaar treats large binary files and are
> there any interesting and relevant switches / options I should know
> about?
>
> Thank you,
>