fu

A Git User’s Guide to Mercurial Queues is pretty good, and has led me to investigate (and use) multiple patch queues.

Guards are much more flexible, and let you disable/enable patches easily, as well as mix and match different groups of patches. Everything you can do with qqueue, you can probably do with a guard.

For my purposes, qqueue is better, though. I don't need all that flexibility. I just want to group patches into logical branches, and be able to work on them as a group, as well as be able to stay "on topic" -- any new patches I create being automatically grouped with the patches I'm currently working on.

qqueue has made a few small changes to my workflow that have made my dev work much easier:
* hg qnew automatically adds a new patch in the same queue you're working on. No need to go back and do "hg qguard +featurename" each and every patch. No more annoying miscellaneous unguarded patches that need to be sorted out!

* hg qq -l brings up a list of all patches in the queue. With hg qguard, to find everything applicable, I'd need to do hg qguard -l | grep $featurename

* hg qq --delete $queuename lets me forget about all patches in a queue with a single command -- just what I need when I'm done with something


I still use guards within the patch queue, but only for small things: I use them to tweak configuration, or to disable a patch before running a test. My tests are almost always in a separate patch from my features code these days ;-)



Disadvantages: it's not easy to move patches from one queue to another and you can't apply patches from two different queues at the same time.

For what I need though, it's perfect.

Hmm, I've been thinking about this a bit, and I'd like to start noting down what I'm working on, informally.

What this means is that I'll be posting more: sometimes I'll be posting more technical stuff, other times I'll be posting less technical stuff. More technical entries like this one, which include code, will be tagged with "development", so you can either filter that out or read only that. We'll see how it turns out.

Today, while reviewing a patch to allow support requests to be mass-closed, I stumbled upon code that was completely unfamiliar to me:

$dbh->selectall_arrayref( "...", { Slice => {} } )

Usually the first argument to one of the database calls is undef; I've never bothered to figure out why, just chalked it up to something that was over my head. Tonight, it was obviously time to figure out what that first parameter was for!

Discovery number one: the first parameter is not magic. It's actually a hashref of additional attributes, in case you need to override the default settings (such as whether to commit, what to do when the database errors, what format to return the results in). Usually we just pass in undef because we don't need to override the defaults.

Discovery number two: perldoc DBI is useful for seeing the entire API of DBI, but it's very technical (I skipped sections that I thought were irrelevant; it turns out that one of those irrelevant portions was actually relevant)

Discovery number three: unrelated to previous, but taken from perldoc DBI, you can look up the last SQL statement that your program used, using warn $dbh->{Statement} or warn $sth->{Statement}. That prints out the last SQL statement into your logs, including the values of any variables -- useful when you're deep into debugging something.

Discovery number four: perlmonks.org has a page for DBI recipes, which was what made me realize that the whole thing with Slice? Was so you could return a list of hashrefs.