From: Daniel Barkalow Date: Thu, 30 Jun 2005 20:49:12 GMT Subject: Re: "git-send-pack" Message-ID: In-Reply-To: On Thu, 30 Jun 2005, Linus Torvalds wrote: > 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*