vcs for hefty video and graphics files

[Masklinn]

On 2010-11-22, at 22:43 , Michael Diamond wrote:
> On Mon, Nov 22, 2010 at 12:32 PM, Masklinn <masklinn at masklinn.net> wrote:
>> In any case, do not even attempt to handle such projects with a DVCS.
>> 
>> I don't know if I would go that far.  The major benefit of a DVCS is that
> it stays on your computer, meaning there are fewer (or no) network
> operations necessary, which would be very valuable on a many gigabyte
> project.  The setup effort for Mercurial is also vastly simpler than SVN or
> Perforce, so that's another perk for a small user.
> 
> The cost is of course your project will take up much more space on your
> drive.  Hard to say how much exactly, but it will be a fair amount.  This is
> no different than a centralized VCS, And only gets worse if you have several
> versions of the repository floating around, which does not sound like it's
> the case for this user.

I'll give you the simpler setup, but that's about it

1. If you fear network latencies, you can install the svn or perforce repo on the local machine
2. DVCS are not targeted towards binary files and that shows: I believe some operations in mercurial require (more than) twice the RAM of the biggest file in the operation. For A/V works, this means gigabytes of RAM for a single operation. hg starts warning when you add files bigger than *10MB* to the repo. My point and shoot generates files bigger than that.
3. DVCS also tend not to focus much on binary diffing, so the repository grows much faster than with a solution taking in account those and trying to bdiff them.
4. big network operations (such as pushing/pulling big binaries) also aren't generally a big concern, and are therefore usually inefficient.
5. bigfiles is essentially a second, binary-only VCS working in tandem with mercurial. Bigfiles also, I believe, translate into losing the distribution part of DVCS, and doesn't implement much in the way of cooperation primitives. If the project is composed solely (or nearly solely) of "big" files, why not go directly with a complete VCS handling those correctly? And future-proof the project in case a collaborator or two are added later on?

> I'm not saying Mercurial or another DVCS is the best option, but I don't
> think it's fair to say it's absolutely not.

As far as my experience and thought experiments go, it is completely and utterly fair to say DVCS are unfit for binary-heavy (let alone binary-only) workflows. They're just the wrong tool for the job. This is not an indictment of DVCS, it's just a problem set they never set out to solve.