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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Date: Tue, 04 Mar 2014 17:26:14 +0900
> Cc: Juanma Barranquero <address@hidden>, Dmitry Gutov <address@hidden>,
>       Andreas Schwab <address@hidden>,
>       Emacs developers <address@hidden>
> 
> 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.

No, we are discussing ChangeLog entries, see the subject line.

For commit log messages, Glenn, whose change started this thread, does
use references to bzr revision numbers, even across branches:

  115194: Glenn Morris 2013-11-23 [merge] Merge from emacs-24; up to r111408

So what you say about bzr revision numbers is not really relevant to
the subject of this thread.

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

No oops.  "bzr pull" makes the target branch a perfect clone
(a.k.a. "mirror") of the source branch.  This in effect nukes the
previous history of the target branch, and replaces it with that of
trunk.  Therefore, pulling from trunk into a branch that doesn't track
trunk is (or should be, at least IMO) done only when the branch's
previous history is no longer interesting, and thus its revno's are
not important.

IOW, a user who "bzr pull"s like that actually _asks_ for the above to
happen.  She asked to destroy the previous history of the branch.  I
agree that referencing revision numbers of such ephemeral branches and
then merging those commits to trunk is unwise at best.  But again,
this is not what started this thread.

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

They are not spurious.  They mark the merges and record the parents.

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

??? As long as the branch history exists and is not overwritten by
pulling from a divergent branch, referencing its own revisions is
stable, AFAIK.  Whether it is wise to do that in branches that are
intended to be merged onto trunk is another question (and my answer is
"probably no").

> It's even unsafe in the same branch if you may pull from upstream.

AFAIU, you should never "bzr pull" from a divergent branch, unless you
want to nuke the history of yours, or as a shortcut of removing the
branch and cloning the remote one anew.