Caching up-to-date revno in a file (was: plugin not working on lightweight checkouts)

Joshua Judson Rosen rozzin at
Mon Nov 30 04:21:05 UTC 2015

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))))."

More information about the bazaar mailing list