Re: Repo cpnversion progress report

[Stefan Monnier <monnier@iro.umontreal.ca>]

> <2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nFixes bug 2317"

(with-nitpick-mode
 Should be "\nFixes bug#2317")

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

For the "Fixes bug#NNN", this cost is not does not accumulate: it was
there already and we just translate it in another form.

For the references, it is true that they can accumulate.  But we
shouldn't say "Bazaar revision NNNN; CVS revision 1.MM; RCS revision 1.PP".
Instead we should only keep the original reference text (in the above
case it would be "RCS 1.PP"), so they don't accumulate either.

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

To reduce the load, you can just skip the "conversion to action stamps".
I think it's more important to preserve their correctness (i.e. not
touch them) than to make them easy to use.

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

I know I won't be using any external data file because I need such
a thing rarely enough that I won't remember where the file is or which
command to use for that.

Also they're rare enough that it's OK if it takes a while to figure out
what it's referring to.

> 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?

He doesn't and moves on.  Or he goes back to the old Bzr repository to
figure it out.

For fixes it's very different.  The way it works is: vc-annotate tells
me the code was changed in commit NNNN and that commit says it's linked
to bug#MMMM so I go check bug#MMMM to try and understand why the code is
the way it is.  This is a fairly common occurrence, and it's common to
use the bug#NNNN reference as an "excuse" to keep the commit log
shorter, so it's important to preserve this info.


        Stefan