On Mon, 11 Apr 2005, Ingo Molnar wrote:
>
> to construct the combo blob later on, we do have to unpack sched.c (and
> if it's already a combo-blob that is not cached then we'd have to unpack
> all parents until we arrive at some full blob).
I really don't want to have this. Having chains of dependencies is really
painful, and now if _any_ of them gets corrupted, you're screwed.
Yes, GIT already has chains, but they are the minimal possible (ie we have
the path-name-dependent tree chain, which I tried to avoid but really
couldn't). The "commit" chain can grow to arbitrary sizes, but losing any
entry but the top one really doesn't lose any data - you lost your place
in history, but at least you're not totally screwed. You still have your
data, you just can't find your way to the root (but you can, for example,
effectively re-create the whole commit chain if you want to without having
to touch any of the data blobs).
So I would very strongly suggest that we do not have dependent combo
blobs, but that if you want to, a better "network protocol" might be quite
possible. Ie send diffs over the network, and re-create the blobs on the
other side. You can trivially check that you got it right, because if you
didn't, the name of the result won't match ;)
Please?
Linus
-
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]
