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