I recently received an email from somebody asking for about experiences using git to do development for Django. It turned out they weren't interested specifically in git, but in how it was working using a different system from the upstream master repository.

Well, I can write a few words about that. I've written about some of my previous experiences here and here, so this is an update based on accumulated experience.

(Read more...)

Topics: software/django, software/version control

[#]

A slightly more technical post today. Apologies to my non-IT readers. Normal interest will resume tomorrow.

Without wishing to start any kind of "my version control system choice is better than yours" debate — because I really, truly, don't care — here are two interesting numbers:

35M     django_working
25M     django.git

The top one (django_working) is a normal subversion checkout, completely up to date (to r5722) and with all .pyc files removed. The second directory is the same thing, except that I also imported all the subversion trunk changes since Django was released to the public (so, from r1 up to r5722).

As the name suggests, the second repository is a git repository, created with git-svn so that I can write back changes to the main subversion repository as well. The initial import was around 140M, but I ran git-repack on it to compress it. There are trade-offs here, obviously; packs take a bit longer to access. By and large, though, I don't need access to all the history and checkins. When I do and I'm offline, this will be invaluable. The ability to use git-bisect on a local copy to find problems will come in handy, too, I suspect. I didn't really care too much how large the storage requirement was (although my laptop is getting a little full, so it might have been an issue there), but the small size was a little unexpected.

(Yes, I know subversion storage is fairly large in general. Yes, I know there are other distributed version control systems out there. Really, I know this. You don't have to email me to tell me. It's not that important.)

Topics: software/django, software/version control

[#]

One of the talks I went to at OSCON was about using mq: patch queue management on top of mercurial, a la quilt.

I had used quilt a couple of times in the past when juggling multiple patches in GNOME, but had gotten out of the habit. Inspired by this talk, I checked out stgit, since I tend to use cogito as my personal version control system of choice these days for various reasons. Patch queues + version control is still a nice combination.

Since getting back home, I've been learning to use stgit to manage my myriad of Django "works in progress" and it's working quite well. This wasn't a hard learning curve: it took all of 15 minutes to read the tutorial and start playing, but it takes a day or two to get used to the commands and tricks and traps. Patch management control systems like this work well for the scenario where I am developing something on top of an already active tree. I update the subversion copy regularly, check the changes into git/cogito, pull them into the branch I am working on with stgit and refresh (the stgit term) my patch. The result is that my working patch is always sitting "on top" of the current subversion code, so I can easily generate a diff and always know it applies cleanly.

Applying a whole bunch of patches from Russell Keith-Magee tonight to another branch went reasonably smoothly, too. Although it did seem to swallow one of the patches without making the changes and another one didn't apply cleanly, although patch had no similar problems. So stgit still needs watching, but I think it will speed up my workflow a little bit.

On Sunday, I had eight or nine different Django working directories (I suspect one was more of a train wreck than a working copy). Today I have four: two are old snapshot versions that I need for working on code for clients, one is a pristine copy of subversion and one is a multi-branched beast with all my patches in it (plus Russell's testing code). It's a little weird using two different version control systems, at once. But I've been juggling that already using cogito and svn previously. Shrinking any new work down to "just a patch" on top of the existing code is the real gain I'm seeing here. It make tracking the changes easier, directory listings shorter and switching between working copies (which one gets used when I run "django-admin.py"?) easier.

Topics: software/django, software/version control

[#]