Re: Bzr document unclear. There is no "conflict markers".

[Bojan Nikolic <bojan@bnikolic.co.uk>]

Hi Richard,

Richard Stallman <rms@gnu.org> writes:

>     I think it is usually better do the merge first (and resolve any
>     possible conflicts) before making the edits that make up your fix.
>
> I find that hard to understand.  If you have not yet edited the file,
> what is there to merge?  All you could do is update, right?
>
> Is there something I don't understand here?

The quick answer is that the "quickfixes" branch could have diverged
from the trunk, for example because some of the developers changes have
not been accepted (yet) into the trunk.

Reviewing the wiki document, I do not it is completely clear on this
topic. The current text on the wiki on this is as follows
(http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc12):

          cd $DEVHOME/emacs/trunk
          bzr update                     # update from the upstream master 
          cd ../quickfixes
          bzr merge                      # update from /trunk/ (optional)

    The reason you use “merge” instead of “update” in the task branch is
    that your task branch has local changes – it has diverged (a bit)
    from the upstream master, and so any changes from upstream have to
    be merged with your changes.

I think there are a few things to add to this.

Firstly, it is not really correct that in the "quickfixes" directory
there is a choice between running "bzr merge" or "bzr update". In fact
(I believe) it is a choice between "bzr merge" and "bzr pull".

Recall, "bzr pull" can incorporate changes where there is no divergence
in history. In this case that will be true if the last revision
quickfixes is on the direct history line of the current last revision in
trunk.

If the histories have diverged, then "bzr merge" must be invoked to
combine them. One possible reason why the histories could have diverged
is that some of the changes that the developer has made on the
quick-fixes branch have not yet been accepted into trunk.

Secondly, if "bzr merge --pull " is called by the developer but "bzr
pull" would have succeeded (because in fact there has been no divergence
in history) then the results is exactly equivalent to "bzr
pull". Therefore I think in these situations it is better to do use the
--pull option to merge.

Best,
Bojan




-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk