Bitbucket.org

[Ondrej Certik]

>> How do you handle this?
>
> Good question, but I'm not sure you'll like my answer:
>
> We don't run hgweb by itself, like your solution relies on. We actually let
> Django handle requests on the first layer, and in there, we check whether
> anything mercurial-y needs to be done. This means that we handle
> authentication/permissions and stuff like that on our own application layer,
> and only when we're ready, we dispatch a request through to the internal
> hgweb. We give it a "dummy request object", which behaves like the
> wsgirequest object hgweb relies on, but instead of sending it to the user
> directly, we buffer it and handle it in a way we can work with.

That's a way better way to handle it.

>
> Before Bitbucket, I wanted to host hg repositories on my own website
> (http://noehr.org/hg/), but I didn't want to run a standard hgweb instance
> (also because it was a pain to set it up with my webhost.) Instead, I did
> what I described above, and we are basically using the same flow on
> Bitbucket. The source for my website *is* open source, so you can see a
> working example of how it works:
>
> http://www.bitbucket.org/jespern/cx/src/6d8cb55ead16/apps/hgwebproxy/views.py

When clicking on the "hgwebproxy" link in the page above, I got:

"
404 - Not Found

We're sorry, but we couldn't find the page you were looking for.

You can perhaps find what you're looking for by doing a search in the
list of public repositories.

If you feel that this is an error on our part, please send us an email
with details about the error and what you were doing when it occurred.

-- The Bitbucket team
"

I think the link address is wrong.

>
> One thing I should mention is that in the source above, we give the
> hgwebdir() function a filename, but it's entirely possible to give it a
> dictionary as well.

I see thanks. Someone needs to wrap it and create a nice django app
that just works.

>
>> Also the apache config is quite complex (and I fear error prone). I am
>> looking for some easy way to make freehg much more easier to install
>> and I think you could help with that.
>
> I'm afraid with the way freehg works, the configuration you have is needed.
> You could look in to making a request wrapper like the one above.

I see. Nice thing about freehg is that it just works, and it's usable.
I hope someone else will wrap your wrapper script with freehg to make
it more easier to work with. :)

>
>> BTW, if you later release some parts as opensource, use a regular
>> opensource license, like BSD or GPL, so that it can go to
>> Debian/Ubuntu, please don't use affero -- I think that license is
>> balancing on the edge of free/non-free. I'd like to have some easy to
>> install package that one can just "apt-get install" and it would
>> provide the hg server hosting. For the time being based on freehg, if
>> we manage to streamline the install a bit.
>
> If we make any individual components open source, we are going to go with a
> very open license. The case Paul described was the entire product, and in
> that case, I do think that Affero is a good one.

Great, excellent!

Ondrej