fu

Mercurial has a setting which tries to figure out what function you're in, and adds that to the patch output. It's really helpful when reviewing, so I recommend turning it on. For example, compare this diff:


--- a/bin/upgrading/s2layers/core2.s2 Tue Aug 30 22:12:52 2011 -0500
+++ b/bin/upgrading/s2layers/core2.s2 Wed Aug 31 04:45:59 2011 +0000
@@ -331,6 +331,8 @@
var readonly Tag[] tags "Array of tags applied to this entry.";

var Image userpic "The userpic selected to relate to this entry.";
+ var Image userpic_orig "FIXME";
+ var int itemid "Server stored ID number for this entry";

var readonly string{} metadata "Post metadata. Keys: 'music', 'mood', 'location', 'groups', 'xpost'. Comment metadata. Key: 'poster_ip'";

@@ -378,7 +380,6 @@
var bool new_day "Is this entry on a different day to the previous one?";
var bool end_day "Is this the last entry of a day?";

- var int itemid "Server stored ID number for this entry";

function print_metatypes(bool icon, bool info) "Print the metatype information for this entry";



With this one:

--- a/bin/upgrading/s2layers/core2.s2
+++ b/bin/upgrading/s2layers/core2.s2
@@ -331,6 +331,8 @@ class EntryLite
var readonly Tag[] tags "Array of tags applied to this entry.";

var Image userpic "The userpic selected to relate to this entry.";
+ var Image userpic_orig "FIXME";
+ var int itemid "Server stored ID number for this entry";

var readonly string{} metadata "Post metadata. Keys: 'music', 'mood', 'location', 'groups', 'xpost'. Comment metadata. Key: 'poster_ip'";

@@ -378,7 +380,6 @@ class Entry extends EntryLite
var bool new_day "Is this entry on a different day to the previous one?";
var bool end_day "Is this the last entry of a day?";

- var int itemid "Server stored ID number for this entry";

function print_metatypes(bool icon, bool info) "Print the metatype information for this entry";




Voila, instant context :) To turn it on, edit your .hgrc file:

nano ~/.hgrc

And then paste this section in it:

[diff]
showfunc=true
git=true


showfunc=true makes Mercurial try to parse out the function the lines are changing in. git=true makes Mercurial behave git-like in some aspects, the most important one being that it'll save changes to binary files (such as images) within the generated patch, so that someone applying the patch will have your image placed into the proper path. That is, without your needing to upload the image separately along with instructions for where the image should go.

You could tie perltidy to the mercurial commit hook, and use that as an automatic checker for style before commit.

We have so much old code in various styles, this would be much easier than tweaking things by hand to make everything conform, and once you've gotten past that first big burst of formatting, you could run it again and see any style issues in any new patches.

And yet, and yet...

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.

The Schwartzian transform came up briefly in conversation in #dreamwidth. It is a way to sort by a calculated value, useful when calculating for said value is expensive.

I think I have seen it before, but I didn't realize it was a common enough idiom to have a name. I like how deceptively confusing it is, but once it is explained line-by-line it suddenly makes sense!

There's lots of nice stuff over at the Test::More documentation. In particular, I've just had a huge "D'OH" moment, and have switched to using is_deeply for many of my new tests where I check complex object structures. (Instead of, say, doing a for loop for each variable).

Oh hey, you can make the jQuery validation plugin do both a summary of all errors before the form, and a per-field error message (best of both worlds?)

I'd been worrying that we'd need to do our own implementation, but now it looks like we don't. Ain't open source grand?

I forgot that this week was mine, oops. Anyway if you have something, comment here *G*

Doing massive massive cleanup of the site CSS. If I do everything right, everything should just work and it should be easier to work on frontend moving forward.

Have committed all patches that I might otherwise break in my cleanup, but ignoring the rest for now so I don't lose my train of thought.

It is just Thursday! That's good, I thought it was Friday and I'd run out of time *g*

Meant to try for a code push this morning, but my connection has been crawling, so I'm putting it off until I have better access. Want to make sure that I don't lose control halfway through.

Will see how things look in a couple of hours.

Was about to post an entry musing about some odd behavior I'd run into on entry preview, and then it occurred to me that I could probably track down the cause with a couple of moments of investigative work.

Few minutes later, I have a patch, a bug filed, and a fix committed.

(The things I get up to while procrastinating from writing the news post, oops)