On Wednesday 2007 May 02, Julian Phillips wrote:
> oops, meant 2.7G not 8.5G there ... sorry, was working from memory.
Not a problem. That fixes one ambiguity:
2.7G - 1.3G = 1.4G
Which is the same as the CVS checkout size. Both the CVS and git figures are
now consistent:
CVS git SVN
Size of data on the server 8.5G 1.3G n/a
Size of checkout 1.4G 2.7G 1.5G
Overhead in checkout 0G 1.3G 0.1G
So that only leaves the subversion number as being suspicious.
> the difference between 2.7G and 2.8G may be due to filesystem difference?
Could be I suppose. Although, in that case CVS should have suffered the same
because the disparity was in the source tree size. Packed git shouldn't
suffer any filesystem overhead (relatively) because the majority of it's
space is taken up by one large pack file (which of course only suffers file
system overhead once).
> I was wondering about the subversion figures too ...
I've just checked using subversion 1.4.2 and the .svn/text-base/*.svn-base
files are all uncompressed copies of the working tree files. Doesn't look
like anythings changed in the pristine copy department.
> jp3@electron: ooo(unxsplash)>ls -sh .git/objects/pack/
> total 1.3G
> 37M pack-87efcac9bcb117328e8a1b0c1b42c88c3603c5b7.idx
> 1.2G pack-87efcac9bcb117328e8a1b0c1b42c88c3603c5b7.pack
Thanks for your help. It's all looking more consistent to me now; only the
subversion figures seem wrong.
I wonder when they're going to get timing numbers for the non-git systems.
That must be a monster of a repository for them to deal with.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@xxxxxxxxx
-
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