On 8/26/07, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Aug 25, 2007 at 11:44:07AM -0400, Jon Smirl wrote: > > > A very simple solution is to sendfile() existing packs if they contain > > any objects that the client wants and let the client deal with the > > unwanted objects. Yes this does send extra traffic over the net, but > > the only group significantly impacted is #2 which is the most > > infrequent group. > > > > Loose objects are handled as they are currently. To optimize this > > scheme you need to let the loose objects build up at the server and > > then periodically sweep only the older ones into a pack. Packing the > > entire repo into a single pack would cause recent fetches to retrieve > > the entire pack. > > I was about to write "but then 'fetch recent' clients will have to get > the entire repo after the upstream does a 'git-repack -a -d'" but you > seem to have figured that out already. > > I'm unclear: are you proposing new behavior for git-daemon in general, > or a special mode for resource-constrained servers? If general behavior, > are you suggesting that we never use 'git-repack -a' on repos which > might be cloned? This would be a new general behavior. There are cases where git-daemon is very resource hungry, rearranging things a little can remove this need for everyone. There are several ways to address the repack -a problem. But the simplest solution may be the best, send existing packs only on an initial clone. In all other cases continue with the current algorithm. We could work on methods for making the middle case better but it is so infrequent it is probably not worth bothering with. Changing git-daemon only for the initial clone case also means that people don't need to change the way they manage packs. Posters have been saying, why worry about initial clone since it isn't done that often. I agree that it isn't done that often, but if it is done all on my NSLU2 it will take about 40hrs to complete. We can easily see the impact of changing the the initial clone algorithm, the http clone takes 3min. BTW, if the NSLU2 needs a repack -a I can do it on another machine and copy it over. Or maybe someone will write a repack that is happy in 20MB. The NSLU2 is a great home server, it is usually fast enough. Power consumption is a tiny 8W, fine to leave on 24/7, My NSLU2 is as powerful as the average desktop machine in the early 90's, how quickly we forget. > > -Peff > -- Jon Smirl jonsmirl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
