Matt Mackall wrote: > On Fri, Apr 29, 2005 at 11:18:20AM -0400, Morten Welinder wrote: > >>>I had three design goals. "disk space" wasn't one of them >> >>And, if at some point it should become an issue, it's fixable. Since >>access to objects is fairly centralized and since they are >>immutable, it would be quite simple to move an arbitrary selection >>of the objects into some other storage form which could take >>similarities between objects into account. > > > This is not a fix, this is a band-aid. A fix is fitting all the data > in 10 times less space without sacrificing too much performance. > > >>So disk space and its cousin number-of-files are both when-and-if >>problems. And not scary ones at that. > > > But its sibling bandwidth _is_ a problem. The delta between 2.6.10 and > 2.6.11 in git terms will be much larger than a _full kernel tarball_. > Simply checking in patch-2.6.11 on top of 2.6.10 as a single changeset > takes 41M. Break that into a thousand overlapping deltas (ie the way > it is actually done) and it will be much larger. > At this level of performance I would say it doesn't matter. If a full checkin take two minutes or three minutes doesn't concern me, because I'm not going to sit and watch it, I'm going to read LKML or write my beer blog in another window. I would care about two vs. three hours, but minutes are too long to wait and too short to care. Now look at pulling 41MB over a T1 link. All of a sudden I care bigtime! I want very much to use my bandwidth for other things, I don't want 41MB added to my backup, etc. Disk space is cheap, but unless you ignore backups and have an OC3 or so, these numbers are large enough to be irritating. Not a huge issue, just one of those "piss me off every time I do it" things. If there is a functional reason to use git, something Mercurial doesn't do, then developers will and should use git. But the associated hassles with large change size, rather than the absolute size, are worth considering. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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.htmlReceived on Tue May 03 04:38:02 2005
This archive was generated by hypermail 2.1.8 : 2005-05-03 04:38:02 EST