Re: Repo cpnversion progress report

[Eric S. Raymond]

Stefan Monnier <address@hidden>:
> > I hear the argument about forensics, but the Bazaar revision numbers
> > are no more helpful for that than the action stamps. If anything,
> > spelunking is an argument for appending those numbers to the change
> > comment of each revision - leaving them in as references would a
> > bass-ackwards approach to the problem.
> 
> Moving the "equiv to bzr r123456" to the commit message of that
> corresponding Git commit sounds like an good compromise.  Of course, we
> don't need it for every commit, but for all those commits that have
> a corresponding "action stamp".

Technically, I could do this.  It would take a minor extension of
reposurgeon, but that is in itself OK because I'm going to have to
build that same primitive to do the thing Eli Zaretskii wanted
(fixes-bugs headers folded into the commit comments).

Let me explain this; it will give some insight into my working methods.
The primitive I plan to add to reposurgeon will be called "append"
or some verb like that.  It will take two arguments; one commit 
identifier, one string.  The effect will be to append the specified
line to the specifed commit comment.

Then, I would extract a list of revisions to be marked from my master
FOSSILS file and compile it into a sequence of append commands.  So, for
ecample, this association:

        100984 -> 2010-08-05T23:34:address@hidden

would compile to this append command:

<2010-08-05T23:34:address@hidden> append "\nBazaar revision 100984"

For Eli's feature, I would build a map from revisions to fixes-bug numbers
by mechanically analyzing the output of bzr log, then generating append
commands like this:

<2010-08-05T23:34:address@hidden> append "\nFixes bug 2317"

All these append commands would be appended to the lift script to be
applied on conversion day.

These things can be done.  The question is whether they *should* be done.
Because with each benefit there also comes a cost.

There is a real cost to burdening the commit comments with an
ever-increasing load of fossil data.  As Paul Eggert pointed out in
connection with references, this will scale badly over time.
Additionally, while none of these processing steps (or many others like
them) are difficult in principle, they accumulate to a huge load
of work for me.

Accordingly, I want to hear a use-case analysis.  That is, rather than
relatively vague hand-waving about forensics I want somebody with a
stake in the process *other than me* to lay out a set of user stories
about what kinds of navigation and lookup we want to support, so that
potential data representations (map file, in-commit comments, etc.)
can be checked against those stories.

Here's an example of a user story:  Someone is reading the emacs-devel 
archives and reads mail containing a reference to an Emacs change by 
Bazaar revision.  How does he get to the corresponding git revision?

What other user stories are there?  What do they tell us about 
acceptable gradients in lookup costs?  What does that tell us 
about good metadata representations?

I think I know what many of the conclusions will look like.  I've
been around this track before!  But others might educate me, and
will certainly educate some of the rest of you.

> > But there's a better way.  We're going to have a complete
> > revision-to-action-stamp map as part of the record.  It would be
> > pretty easy to write Emacs code that uses that map to find revisions
> > by Bazaar reference number.  That's the right solution, IMO.
> 
> But where would this map be stored?

/etc, same as any other static data used by a mode.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>