Large Binary Files

[Stephen J. Turnbull]

Chris Hecker writes:

 > experience, but, the following points seem to be the case right now with 
 > bzr/hg/git:
 > 
 > 1.  There are no partial checkouts,

Not true for git, which supports submodules, or hg, which has forests.
Perhaps scmproj could be used to handle this for bzr.

AFAIK these will require a certain amount of extra management by
release managers.  No specifics for hg forests, but in the case of git
submodules the submodule is tied to a specific commit in the
subproject, so the RM will need to keep track of what the "artists"
consider releasable, the "engine dev team" considers releasable,
etc. and update the relevant submodules in the release branch by hand.

 > 2.  There is no way to store a subset of the history locally,

Not true in git or bzr.  In bzr, at least you have the option of zero
local history with a so-called lightweight checkout.  With git you
have the option of a "shallow clone", bounding the history in the
initial checkout.  However, it basically prevents you from
communicating with upstream via git, so probably not an option.  You
might want to watch git for improvements on this, although the
occasional bzr bug with "ghost revisions" suggests that handling such
partial histories is not easy.  bzr and git also allows the option of
putting your shared repo (bzr) or object database (git) on a
distributed file system such as NFS.

 > 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.

Yup.  I don't know if it would be possible to actually lock the file
in bzr, but again bzr's lightweight checkout is the closest thing in
DVCS to what you want here.

Considering all the above, along with the 2GB limit (at least on 32
bit workstations), it seems like DVCS is not quite ready for prime
time here.