On Thu, 26 Oct 2006, Andreas Ericsson wrote:

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

David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html