bugmap extension (was re: API question: ancestors of B that are not ancestors of A)

[Nicolas Dumazet]

2009/12/10 Greg Ward <greg-hg at gerg.ca>:
> On Wed, Dec 9, 2009 at 7:42 PM, Nicolas Dumazet <nicdumz at gmail.com> wrote:
>> 2009/12/10 Greg Ward <greg-hg at gerg.ca>:
>
> Yeah, it is a pretty nifty extension, if I may say so myself.  ;-)
> It's a carryover from our current CVS workflow, which mandates that
> checkin messages start with "BZ#####" so that we can connect checkins
> back to Bugzilla bugs.  There are two little problems carrying that
> habit over to Mercurial: 1) developers are human and make errors, and
> 2) Mercurial's changelog is immutable: you cannot fix your errors.  So
> I wrote 'bugmap' to track the changeset/bug mapping externally.  Once
> that mapping gets into a relational DB (which happens when you push),
> all sorts of interesting things become possible.  Like figuring out
> which bugs are fixed in changeset B but not in A.  Or trivially going
> from bug ID to a list of changesets.
>
[...]
>
> Anyways, I'll attach the source for the extension if anyone is interested.

Great, thanks.
I just read the docstrings/usage to have an idea of your workflow.
It's very promising indeed, but a bit different from my expectations.

I would not like, personally, "setbug" to be able to change bugmap
associated to already propagated changesets. In fact, I imagined  bug
information to be commit metadata, quite similar to tags in kind, with
no way to directly manipulate remote history.
But I guess that you _need_ this behavior.

I still like it. I'll have a closer look at code later, to see how
much of your in-house practices are coupled to the extension, and if
it's hard to make this generic.

-- 
Nicolas Dumazet — NicDumZ