On Wednesday 2007 May 02, Julian Phillips wrote:

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

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

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

quoted text
> 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@gmail.com
-
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