On Fri, 1 Aug 2008, Sverre Rabbelier wrote:Did he retry the size calculation? I think someone on the list tried it and found that the clone, including the checkout, was (for them) the size that he thought was just the database; if you're used to having the clone equivalent be effectively --bare by default, it's an easy mistake, especially if you don't think it's possible for the entire project history to be smaller than a checkout. Not that it actually matters to the comparison of monotone and SVN that was the actual point, but still, git is often more space-efficient than SVN even just on the client, even without any sharing between branches, just because uncompressed source is (relatively) huge. Which does, in a way, contribute to the point that SVN have a vast quantity of per-branch overhead. -Daniel *This .sig left intentionally blank* -- 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
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Nicolas Pitre | Re: [RFC patch 08/18] cnt32_to_63 should use smp_rmb() |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
