Re: "git-send-pack"
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Jun 30, 2005, 20:49 UTC
- Message-ID
- <Pine.LNX.4.21.0506301611000.30848-100000@iabervon.org>
- In-Reply-To
- <Pine.LNX.4.58.0506301302410.14331@ppc970.osdl.org>
On Thu, 30 Jun 2005, Linus Torvalds wrote:
Show 23 quoted lines
> On Thu, 30 Jun 2005, Daniel Barkalow wrote: > > > > The right solution probably involves getting each pack file you push to > > the mirrors as well as to the master. They'll probably update no less > > frequently than you push, and they should go through a series of states > > which matches the master, so it's not necessary to have anything smart on > > master sending them, and they only have to unpack the files they get (and > > update the refs afterward). > > Hmm, yes. That would work, together with just fetching the heads. > > It won't _really_ solve the problem, since the pushed pack objects will > grow at a proportional rate to the current objects - it's just a constant > factor (admittedly a potentially fairly _big_ constant factor) > improvement both in size and in number of files. > > So the mirroring ends up getting slowly slower and slower as the number of > pack files go up. In contrast, a git-aware thing can be basically > constant-time, and mirroring expense ends up being relative to the size of > the change rather than the size of the repository. > > But mirroring just pack-files might solve the problem for the forseeable > future, so..
Whenever it gets slow, you could replace all the old packs with a single new pack containing all the old objects; and master could repack whenever it has a lot of pack files. That's pretty close to O(n) in change size.
Alternatively, having a reverse-ordered list of pack files would mean that mirrors could just go through that list until they found one they already had, and stop there, which would really be O(n).
-Daniel *This .sig left intentionally blank*