Bitbucket.org

Jesper Noehr jesper at noehr.org
Fri Aug 1 04:58:03 CDT 2008


On Aug 1, 2008, at 11:42 AM, Ondrej Certik wrote:
> On Fri, Aug 1, 2008 at 11:33 AM, Jesper Noehr <jesper at noehr.org>  
> wrote:
>>
>> On Aug 1, 2008, at 11:24 AM, Ondrej Certik wrote:
>>>
>>> On Fri, Aug 1, 2008 at 10:51 AM, Jesper Noehr <jesper at noehr.org>  
>>> wrote:
>>>>
>>>> On Aug 1, 2008, at 10:29 AM, Paul R wrote:
>>>>>
>>>>> On Fri, 1 Aug 2008 09:29:12 +0200, Jesper Noehr <jesper at noehr.org>
>>>>> said:
>>>>>
>>>>> Jesper> Hosting isn't free. There's really no magic to the site,
>>>>> Jesper> anyway.
>>>>>>
>>>>>> --
>>>>>
>>>>> Jesper> Let me clarify: Our servers are hosted in a datacenter,  
>>>>> and we
>>>>> Jesper> pay for that out of our own pockets. That's not free.  
>>>>> Hosting
>>>>> Jesper> *with* us is free :-)
>>>>>
>>>>> GPL v2 and v3 apply whenever program bits are distributed.  
>>>>> BitBucket,
>>>>> being an hosted service, can't be *itself* "open-source" or
>>>>> "closed-source". The code behind the scene, itself, could be  
>>>>> licenced
>>>>> *if it were distributed in any way*. But AFAIK, nobody here own  
>>>>> a copy
>>>>> of this software, except the copyright owners themselves.
>>>>
>>>> This is true. We have yet to decide on a license, but it's largely
>>>> irrelevant as we're not planning to open it up (yet.)
>>>>
>>>>> So, Jesper, if I'm right BitBucket provides a service of mercurial
>>>>> hosting, free of charge for a certain category of projects, paid  
>>>>> for
>>>>> other categories, but the software you developed to get this  
>>>>> service
>>>>> running is kept for your service only and not distributed in any  
>>>>> way.
>>>>
>>>> Right.
>>>>
>>>>> So maybe you can develop on : "Why do you beleive your incomes are
>>>>> more guaranteed if you don't share the program ?"
>>>>
>>>> Because if we release the source, nothing keeps other people from
>>>> launching their own Bitbucket instance and charging lower fees (or
>>>> doing it for free, for that matter.) I'm a firm believer in open
>>>> source, and I would like to release the source to the public, but
>>>> there are certain aspects to that which would make it a bad  
>>>> decision.
>>>> That being said, there is  possibility that we will release the  
>>>> source
>>>> later on, after we have (hopefully) gained some marketshare, and  
>>>> don't
>>>> have to struggle to be noticed. We're not keeping it to ourselves
>>>> because there's any kind of secret sauce in there.
>>>
>>> Of course. Thanks for doing it, mercurial needed something like this
>>> for a long time. People that just want to host their own repo can do
>>> that easily with freehg, I wrote a wiki how to set it up here:
>>>
>>> http://www.selenic.com/mercurial/wiki/index.cgi/HowToSetupFreeHg
>>
>> I read your guide earlier, thank you very much for taking the  
>> effort to do
>> it!
>>
>>> I support the business model as well and, btw, that's why I prefer  
>>> BSD
>>> over GPL for certain projects (like libraries), so that companies  
>>> can
>>> even sell the software and thus making it more widespread.
>>>
>>> That said, if you make some parts of your site opensource later,  
>>> it'd
>>> help other people in creating similar sites thus making mercurial  
>>> more
>>> useful.
>>
>> I am planning on this, and I try to keep my code commented and
>> "community"-ready. Several people (off-list) have been very  
>> interested in
>> how we are doing certain things, and we are happy to share. If  
>> anybody here
>> has a question as of to how we accomplish certain things, by all  
>> means, ask
>> away. Other than that, I don't feel like there's anything  
>> spectacular about
>> our codebase, and hence I haven't packaged anything up and put it  
>> out there.
>> If we do get around to doing something really cool, we will release  
>> the
>> source.
>
>
> Yes, I do have a question. If you look at my guide above, it's quite
> pain to install it, you need to setup apache (that is ok), but then
> you need to fiddle with /etc/mercurial/hgrc, which I don't like at
> all. Is there some easier way?
>
> 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.

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

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.

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

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


Jesper



More information about the Mercurial mailing list