[PATCH 0 of 2 bfiles] support HTTP stores (as client and server)

[Greg Ward]

On Thu, Jun 3, 2010 at 6:47 PM, alexandru <alex at hackd.net> wrote:
> This series implements HTTP stores, so you can push/pull/verify big files over HTTP.

Thank you!  This looks very good.  Some random comments:

  * Would you mind using your full name in the commit?  Pretty soon
now I have to write down the list of contributors, and just plain
"alexandru" is a bit vague.

  * I think your patches are in the wrong order: after applying the
client-side changes, bfput over HTTP cannot possibly work.  Apply the
server-side change first, and we avoid that problem.

  * I'm unclear how this would be deployed.  If I understand, it looks
like the admin of the machine where the central store lives will have
to arrange for "hg bfserve --http" to be called in some circumstances.
 When?  On every request? At system startup?  What if I want to use
(say) Apache as the front-end (for SSL, authentication, etc.) -- would
I have to setup mod_proxy?

  * tests?

  * terminology: I deliberately use "put" rather than "push".  You
push changesets, but you put big files.  I saw one or two comments
that said "push" but should say "put".  Likewise you pull changesets
but get big files.  (Early on, bfupdate was going to be called bfget,
but then I realized it has to delete files too.)

Another way to provide the server-side component of this would be as a
CGI or WSGI script -- e.g. "hg bfserve --cgi /path/to/store".  Then
the admin has to arrange for Apache to run that for certain URLs.
That's more consistent with how hgweb works, which I think is nice.

OTOH, a standalone HTTP server is much easier to write tests for.  Hmmmm.

Greg