Re: [RFC] Design for http-pull on repo with packs

One very minor problem I have with Holmsand approach [*1*] is that the original Barkalow puller allowed a really dumb http server by not requiring directory index at all. For somebody like me with a cheap ISP account [*2*], it was great that I did not have to update 256 index.html files for objects/??/ directories. Admittedly, it would be just one directory object/pack/, but still...

On the other hand, picking an optimum set of packs from overlapping set of packs is indeed a very interesting (and hard combinatorial) problem to solve. I am hoping that in practice people would not force clients to do it with "interesting" set of packs. I would hope them to have just a full pack and incrementals, never having ovelaps, like Linus plans to do on his kernel repo.

On the other hand, for somebody like Jeff Garzik with 50 heads, it might make some sense to have a handful different overlapping packs, optimized for different sets of people wanting to pull some but not all of his heads.

Having said that, even if we want to support such a repository, we should remember that the server side optimization needs to be done only once per push to support many pulls by different downstream clients. Maybe preparing more than "list of pack file names" to help clients decide which packs to pull is desirable anyway. Say, "here are the list of packs. If you want to sync with this and that head, I would suggest starting by getting this pack."

[Footnotes]

*1* I was about to type Dan's, but both of you are ;-).

*2* Not having a public, rsync-reachable repository gave me a lot of incentive to think about issues to support small/cheap projects well ;-).