Re: Merging emacs-23 into trunk

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

Eli Zaretskii writes:

 > > Actually, I'm not cherry-picking
 > 
 > I think you are.  From the docs of "bzr merge":

You of all people whould know better than to trust the Bazaar docs!

There are two different, though closely related, definitions, of
"cherrypicking" in practice.

Definition 1, "merging individual revisions, or a subset of available
revisions", is the one used by the Bazaar documents and the Bazaar
developers.

Definition 2, which is the one Stefan is implicitly using, is "merging
individual revisions, or a subset of available revisions, *forcing the
VCS to forget* associations between changes and revisions."  (My
wording is a bit awkward because this subtlety is almost never made
explicit; this is the first time I've tried.)

In the DAG-oriented VCSes (git, Mercurial, Bazaar), there is no
practical difference because once you ask for an out-of-order patch
application the DAG no longer applies simplistically; in particular,
you can't compute the ancestor for a three-way merge.  By design they
forget.  ("git filter-branch" and "git rebase --interactive" are hacks
allowing you to provide the necessary information out-of-DAG.)

GNU Arch (and Darcs) know which changes have been applied to the tree;
there is no presumption that they are applied in history-determined
subsets.  (The difference between Arch and Darcs is that Arch required
the user to try applying and then resolve conflicts at the changeset
level, one after another; Darcs is smart enough to compute where
conflicts will occur, and it then rearranges hunk order to maximize
automatic application before asking the user to resolve conflicts.)

Stefan, who is familiar with both GNU Arch and Darcs, I believe,
correctly perceives Bazaar behavior as a huge regression vs. Arch in
this respect.