Preamble This article is two things:
A description of one way to use version control with a Django project An introduction to using the darcs distributed version control system in particular First, though, a mini-sermon which someday will be a post in the You Really Should series: You really should use version control. Most of you probably do. But if you’re among those not using version control to manage your software projects, start now!
An energy conservation law from 2005 makes Daylight Savings Time (quaint US custom) begin earlier this year – this coming Sunday, to be exact. It’s supposed to be saving us energy, but I’m not sure if the upgrade costs were factored in. Anyway, I have a couple FreeBSD servers that needed the update. Went like this:
sudo portinstall misc/zoneinfo
sudo tzsetup
It took three times longer to find this information (buried at the bottom of this notice) than it did to implement the fix.
When I’m doing Django development work I sometimes find my way to the #django channel on freenode.net to exchange advice. As has been the case on the Interweb since ancient days, certain Questions are Frequently Asked there, so I decided to try the experiment of making a FAQ specifically addressing those questions. Hopefully it won’t be too redundant of other material in the wiki – but if it is, I’m sure the group refactoring intelligence will take care of it.
My personal record of using revision control for source code has been pretty spotty. Today I took steps toward fixing that by working out a system for managing my Django projects. I wanted revision control (Subversion), I wanted Django’s “runserver” for development and mod_python for deployment, and I didn’t want it to be a pain.
Some highlights of the process:
I used my pastebin site as the test mule. I checked in the current live site’s source code, created “trunk”, “tags”, and “branches” directories per the Subversion manual, and checked out a copy of the trunk into a staging directory.
(There’s got to be a name for blog posts that you make just so you’ll be able to remember something later – or so somebody who is banging their head against a problem you just solved can find your solution via Google magic. This is one of those posts.)
A while back I started getting bizarre errors when using Python with MySQL. They looked like this:
python in free(): warning: junk pointer, too high to make sense
It didn’t make sense to me either!
One of the great things about Django is its simple and flexible URL handling. If your Django work, like mine, includes converting existing sites, you’ll probably be doing some URL cleanup along the way. Django’s “generic views” system includes a view called “redirect_to” that handles cases like this. A rule might look like this:
urlpatterns = patterns('django.views.generic.simple',
('^foo/oldsite/BadOldUrl33247.blech$', 'redirect_to', {'url': '/bar/nice-new-url/'}),
)
But because the URL pattern building happens in Python, if you have many of these you can do better than filling your urls.
In an effort to shed time-sucking side projects in the past couple years I’ve let a number of sites go dark and domain names lapse. Some of these were ideas that never got off the ground, but one or two were sites with real traffic and Google pagerank (PR 5 in one case, not stellar but not achievable overnight either).
Sadly, some of these domains have now been taken over by those useless squatter pages that manufacture lists of “related links” and “popular searches” and so on to trick people into clicking on ads.