I’m working at Nelen & Schuurmans and we’ve got some 10 people working with Django (out of 30-40 total). Quite a sizable group. And virtually all our software is open source (GPL). Quite specific software, but GPL nonetheless.
Of course, everything is in version control. In our case subversion, combined with trac for issue tracking. Works fine. But all those new-fangled distributed version control systems (bzr, git, hg/mercurial) looked mighty fine, too. I won’t delve into too many details, but here are some observations:
Git, bzr, hg. Well, bzr (‘bazaar’) is out. I’ve used it personally for a while and it is/was slow. After two years of “but the next version is fast”, I just don’t bother anymore. And the repository format kept changing. At a certain point I couldn’t push anymore to the repository on my server as the bzr version there was a bit older… It took my an hour of version-juggling to get everything working again. Bye bye bzr.
Oh, and git and hg are the two most popular ones. Bzr doesn’t come close.
Hm. Likewise, hg doesn’t come close to git. But hg is big, too.
Actually, the difference is more between “github” and “bitbucket”. If we’re going to use git, we’ll use github. And for hg we’ll use bitbucket. Our code is open source, so we want to make it available.
Actually, that’s a pretty good reason for a distributed version control system: we can move from our internal subversion system to a public distributed one. Yeah, we can move subversion over to sourceforge or so, but that doesn’t make much sense.
Distributed version control is much better at merging. We ought to use branches more, so this is a good point.
And it is quicker. Important, as our internal subversion used to be dog slow. Since the server crashed (well, it ran out of disk space and our sysadmin was on holiday and we didn’t have the password for this one single server…), we moved it off the windows machine onto a fresh ubuntu server and it has been fast since.
Also important is the psychological effect of djangocon.eu. We attended with three of us. When you’re watching three days of presentations and see that most of them have a github link on their last slide… The bitbucket talk was one of the few without a github link :-) Some conclusions we/I drew from that:
I sure like(d) bitbucket a bit more than github, but github is really where the action is.
Do you still use subversion? Hand me that shovel, will you? Then I can bury you with yonder obsolete dinosaurs.
Everything is on github.
To be a good open source citizen, your project needs to be on github (or bitbucket). Oh, and on readthedocs.org.
In the end, we had to make a choice between github and bitbucket. I was in favour of bitbucket, but switched to the github camp after much thinkwork. The basic dilemma is simple:
Git and hg are functionally basically equivalent.
Hg is much friendlier than git. They accomplish the same, but hg manages to
have sane names for its commands where git goes out of its way to be a pain
in the ass. Why o why o why. Git still irritates me when a git st
doesn’t work. You need to type in the full git status
command. Every
subversion user types svn st
instead of svn status
. “It is good to
irritate everyone used to subversion in order to get them to understand git
better” is apparently the thought. Even though hg, which does virtually the
same as git, has sane names and commands for the very same concepts.
Github blows bitbucket out of the water. At the moment, github is a bit ahead in features, but the important point is the user base. Github’s user base is probably an order of magnitude bigger than bitbucket’s.
So what you want is a github that works with hg….
The reason for me to eventually make my choice and to suggest github: https://github.com/plone. Plone (the biggest Python CMS, for those that don’t know it) is switching over to github from their own subversion repository. I worked with Plone for a long time and know and respect a lot of technically very adept people there. So their judgment is important to me.
There was a questionaire a year ago or so about the options. Keep svn, own git, github, own hg, bitbucket. The results were clear: I’m amazed how clear the vote result is! We don’t have to wait any longer to draw a conclusion: We want to move to Github.
Well, we at Nelen & Schuurmans have two accounts now:
https://github.com/lizardsystem for our django applications and so. A the moment (2011-09-30), I’ve got two projects in there. More will be moved next week.
https://github.com/nens for the django sites. These will be private. They’re
GPL, but there’s customer data in there sometimes so we don’t actually
distribute it ourselves. Most sites are pretty empty, though, with just a
setings.py
, some fixtures and a customer logo. We did want a separate
account for this as it makes it easier to treat the django apps as the
re-usable generic apps that we want them to be. And they’re part of our
Lizard information system that we intend as an open source platform for
water-related geographical data, so it is good to keep that separate from
our company’s github account.
Github, here we come.
Now if I only can get all those commands loaded in my head… :-)
Well, at least github publicly says that biking to work is awesome, so that earns them a couple of points in their favour from me.
My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):