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.
pgprtH5qKn2ej.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
