Large Binary Files

[Chris Hecker]

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

The 2gb limit for a single file is not usually a problem, since it's 
rare that a single file will be that big.  Unless the 2gb limit is on 
the total history of a file, and then that's a problem...

Some game developers are runing bzr/hg/git on the source code, and 
svn/p4 on the binary assets, which obviously sucks, but at least gives 
you something.

Chris


On 2010/10/13 21:56, Stephen J. Turnbull wrote:
> 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.
>