June 21, 2012

New Django mercurial mirrors aimed at production servers

by orzel
Categories: Admin, Django
Tags: ,
Comments: 4 Comments

When Django was still using subversion, I used to mirror stable branches (1.2 when I started, 1.4 recently). This worked well and I could clone those repositories on production servers, and then it was just a matter of ‘hg pull -u’ to bring updates/fixes.

Now.. Django has moved to git. I won’t comment on how bad a choice this is and how they should have followed the smart decision of the Python communauty and decide upon using mercurial (oh? did I comment ? πŸ™‚

So, how can I get back my production mirrors ? There are some mercurial mirrors on bitbucket, but they are either broken or incomplete, so I set up my own one.

The purpose for my “production” mirrors is to follow stable branches easily from production servers. And of course, I’d rather have my clones as small as possible. General purpose mirrors got the whole history for every branch and so on, which is too big and useless. For example, a fresh clone from my (full-blown) mirror weights 110 Mb. Compare this to the 34M for a clone of my previous-and-now -broken production mirror.

I can slightly improve things by only cloning the relevant branch, as in

hg clone -r releases/1.3.X http://bitbucket.org/django/django django-1.3

This is slightly better : .hg is now 70M. You can check incoming changests and update with

hg in -r releases/1.3.X
hg pull -r releases/1.3.X

I could not find any better solution so far. There’s still no partial checkout available with mercurial, and until this, I’ll stick with this method.

So here they are, production mirrors for the 1.3 and the 1.4 branch. I don’t need older branches, but if there’s enough interest, I could mirror 1.2 and 1.1 as well. They are updated at the same frequency (it’s the same script, actually) that the global mirror.




In case of problem with those, you can report a problem using the “contact” tab on this blog.


  1. Diederik van der Boor says:

    > I won’t comment on how bad a choice this is and how they should
    > have followed the smart decision of the Python communauty and
    > decide upon using mercurial (oh? did I comment ? πŸ™‚

    Ok, I’ll bite. πŸ™‚
    As pointed out nicely on http://www.holovaty.com/writing/django-github/:

    Github (django/django-old)
    Watchers: 4,030
    Forks: 753

    Followers: 266
    Forks: 39

    That’s not a difference that I think the core team could ignore.

    Secondly, consider using the http://hg-git.github.com/ plugin if you (and I agree on that) find the mercurial interface simpler. However, considering just about every other Django-related Open Source project is found on GitHub, it makes sense to me to use *one* tool, and learn *one* tool. Hence, git is it.

  2. I got the point πŸ™‚
    I would just point out that, as I’ve said, the mercurial mirror has been regularly broken for several years, so obviously that reduce the number of people using it.

    (but still, git sucks and mercurial rocks, ain’t it so ?)

  3. Diederik van der Boor says:

    Glad you’re taking it so positively. πŸ™‚ The issues with the hg mirror could indeed contribute to reduced usage of the mirror, that makes sense to me! Still I think the difference is pretty big πŸ˜‰

    In case you need to learn git, I hope you like my tutorial about it (http://www.codingdomain.com/git/) as I too had to learn it and that took some time. I do like git a lot πŸ™‚

Leave a Reply

Your email address will not be published.