Caching up-to-date revno in a file (was: plugin not working on lightweight checkouts)
Joshua Judson Rosen
rozzin at hackerposse.com
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