From: David Lang Date: Thu, 26 Oct 2006 17:04:34 GMT Subject: Re: VCS comparison table Message-ID: In-Reply-To: On Thu, 26 Oct 2006, Nicolas Pitre wrote: > On Thu, 26 Oct 2006, David Lang wrote: > >> On Thu, 26 Oct 2006, Andreas Ericsson wrote: >> >>>> >>>> There are _not_ scalability improvements. There may be some slight >>>> performance improvements, but definitely not scalability. If you have >>>> ever tried to use git to manage terabytes of data, you will see this >>>> becomes very clear. And "rebasing with 3-way merge" is not something >>>> often used in industry anyway if you've followed the more common models >>>> for revision control within large companies with thousands of engineers. >>>> Typically they all work off mainline. >>>> >>> >>> Actually, I don't see why git shouldn't be perfectly capable of handling a >>> repo containing several terabytes of data, provided you don't expect it to >>> turn up the full history for the project in a couple of seconds and you >>> don't actually *change* that amount of data in each revision. If you want a >>> vcs that handles that amount with any kind of speed, I think you'll find >>> rsync and raw rvs a suitable solution. >> >> actually, there are some real problems in this area. the git pack format can't >> be larger then 4G, and I wouldn't be surprised if there were other issues with >> files larger then 4G (these all boil down to 32 bit limits). once these limits >> are dealt with then you will be right. > > There is no such limit on the pack format. A pack itself can be as > large as you want. The 4G limit is in the tool not the format. > > The actual pack limits are as follows: > > - a pack can have infinite size > > - a pack cannot have more than 4294967296 objects > > - each non-delta objects can be of infinite size > > - delta objects can be of infinite size themselves but... > > - current delta encoding can use base objects no larger than 4G > > The _code_ is currently limited to 4G though, especially on 32-bit > architectures. The delta issue could be resolved in a backward > compatible way but it hasn't been formalized yet. > > The pack index is actually limited to 32-bits meaning it can cope with > packs no larger than 4G. But the pack index is a local matter and not > part of the protocol so this is not a big issue to define a new index > format and automatically convert existing indexes at that point. the offset within a pack for the starting location of an object cannot be larger then 4G.