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