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

[Junio C Hamano <junkio@cox.net>]

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 ;-).