I'm not super comfortable aiming external tools into the .bzr directory...there must be a hook for what I want, no? Chris <div class="gmail_quote">On Nov 29, 2015 8:21 PM, "Joshua Judson Rosen" <<a href="mailto:rozzin@hackerposse.com">rozzin@hackerposse.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/29/2015 05:06 AM, Sebastien Alaiwan wrote: > On 2015-11-29 09:56, Matthew D. Fuller wrote: >> On Sun, Nov 29, 2015 at 09:53:33AM +0100 I heard the voice of >> Sebastien Alaiwan, and lo! it spake thus: >>> Is this the expected behaviour? Not updating the "revno" file on >>> "bzr update -r XXX" commands seems error-prone, as you might want to >>> build older revisions of your project. >>> >>> I was about to suggest to directly use, from your build system, the >>> ".bzr/branch/last-revision" file. However, this will couple your >>> build system to bazaar ; which you probably want to avoid. >> Technically, you'd want to be directly using .bzr/checkout/dirstate, >> since you care about the WT rev, not the branch rev. >> > Thanks for your suggestion. Then, I'd better go for the plugin approach than trying to parse 'dirstate' with a one-liner in a build system. Well, you don't necessarily have to *parse the dirstate* with the build-system. :) What I've done in Makefiles (with or without Automake) is to just have a rule like: revno: $(wildcard .bzr/checkout/dirstate) bzr revno --tree > $@ That leaves the parsing to bzr, but avoids having to run bzr every time the Makefile is run. (I don't actually dump a "revno" file, but I do use a rule like that to autogenerate my ChangeLog files for "make dist"; using the "wildcard" function like that prevents make from barfing on a `broken' rule-chain when .bzr/checkout/dirstate doesn't exist--as is the case when someone has unpacked a dist tarball--but still DTRT when bzr data is present). -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))." </blockquote></div>