Re: [Emacs-diffs] trunk r116644: ChangeLog entries should be usable without the VCS

["Stephen J. Turnbull" <stephen@xemacs.org>]

Alan Mackenzie writes:
 > 'Evening, Andreas!

 > > Neither revision numbers nor hashes are readable.
 > 
 > On the contrary, r116644 is eminently readable and memorisable,

But here we're discussing use in log messages.  Besides Andreas' point
about lack of log information, unlike the hash, it's context-dependent
and unstable.  It means different things in different branches, and
even different things in different instances of (what users consider
to be) the *same* branch.  Consider:

Before merge:

trunk branch (== working copy of trunk, cloned at r10)

  |     |
 r10 = r10
  |     |
 r11   r11
        |
       r12 ... "fix bug introduced in r11"

Note two r11s, and the log message refers to the unstable one.  After
merging into trunk:

  |
 r10
  |\
  | \
  |  r10.1.1
 r11    |
  |  r10.1.2 ... "fix bug introduced in r11"
  | /
  |/
 r12

After pulling merge back into branch:

  |
 r10
  |\
  | \
  |  r10.1.1
 r11    |
  |  r10.1.2 ... "fix bug introduced in r11"
  | /
  |/
 r12

Oops.  This happens because bzr pull insists on duplicating the DAG,
which is nice for later development in some ways.  You could merge
from trunk instead of pulling, which would preserve the branch's
numbering.  But then the DAGs are different, and after merges to trunk
bzr log will show those merges as spurious isolated merge commits.

As far as I can see, there is no way to refer stably to a revision in
a non-trunk branch from a later revision in that branch, unless it is
never merged into another branch at all.  It's even unsafe in the same
branch if you may pull from upstream.

Often, perhaps most of the time, a fix in branch will use a revision
number reference because it happened "far away", probably in trunk (or
a branch already merged to trunk and obsoleted).  In the case of
revision numbers referring to trunk numbering, this will be OK.  I
prefer the much higher reliability (ie, SHA1 collision probability) of
hashes since both are unreadable in Andreas' sense, but YMMV.