Re: [Monotone-devel] Rosterify and certificate keys

[Daniel Carosone]

On Mon, Apr 10, 2006 at 11:09:11PM +0200, Richard Levitte - VMS Whacker wrote:
> The revs in the merge and propagate changelogs are really
> irrelevant, the ancestors of the merge/propagate are registered
> separately, and are always correct.  

The direct ancestors being merged may be, but the chosen common
ancestor is not (eg, explicit_merge).  I can see this being important
on some (rare) occasions, though hopefully the need for explicit_merge
in the future also diminishes!

> Of course, that doesn't help
> your hand written changelogs, but then, in what situations do you
> end up writing down a specific revision hash?

Typically, when referring to another change done previously but which
was somehow erroneous or incomplete; maybe it needs to be backed out,
or re-done or completed, or something else needs to be regenerated
accordingly.

This, perhaps, brings up a style issue.. In linear VCSs, you have no
choice, and changes like this if they happen quickly enough (before
other revs intercede) are often described as "fix foo in previous", or
with an explicit revid if several revs are in the middle.

In monotone, I've rapidly developed a preference for going back and
committing such changes as a direct descendant of the original
offending revision, and then merging back (rather than making changes
in-line to the current head).  This is the way that the ill-named
'disapprove' works, but it's just as appropriate for other similar
manually-edited changes.

The revision graph then very clearly shows the span of revisions with
the faulty code; with suitable cert annotations and other (future)
tools this can be of great advantage to release engineering and other
processes.

In the context of the present discussion, it also means that some of
the need for references to explicit revid's in changelogs goes away.
The remaining cases are probably cherry-picking style changes, where
the one change gets applied (as a patch) indepentendly to several
branches, and the log refers to the revision where the change was
first added.

I have floated the idea of a "revalias" cert, and corresponding
selector or selection option, that could be applied to revs of
particular interest (or even to all revs, during a history rebuild) --
but to some extent I'd like to see the need for such a thing go away
instead.

--
Dan.

pgpFmMK38mvK6.pgp
Description: PGP signature