On Fri, 1 Aug 2008, Sverre Rabbelier wrote: > On Thu, Jul 31, 2008 at 20:13, Sverre Rabbelier <alturin@xxxxxxxxx> wrote: > > I just read this blog post [0] in which one of the Pidgin devs sheds > > his light on their 'tool choice'. In the post he mentions the > > following figures: > > > [0] http://theflamingbanker.blogspot.com/2008/07/holy-war-of-tool-choice.html > > I have poked him on #pidgin, and he has added the following: > > "Note: It's come to my attention that I had missed the ability to > share a git database across multiple working copies. In that scenario, > the total size of the database and 11 working copies is slightly under > 750 MB, and thus a space savings in the neighborhood of 150 MB over > monotone. It had been my understanding that I needed a copy of the > database per working copy. I stand corrected. I don't use git on a > daily basis, as the projects I work with currently use CVS, SVN, or > monotone, so I am bound to miss finer details of git here and there. > There are other reasons I prefer to stick with monotone, but I won't > get into them here, as they're not important to the point of this > post." 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html