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 ([email protected])
"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 linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
