Re: Help me unstick my bzr, please.

[Eli Zaretskii]

> From: Lennart Borgman <address@hidden>
> Date: Sat, 16 Jan 2010 10:16:37 +0100
> Cc: Giorgos Keramidas <address@hidden>, address@hidden, address@hidden
> 
> On Sat, Jan 16, 2010 at 8:48 AM, Eli Zaretskii <address@hidden> wrote:
> >>
> >> > When I execute bzr status, it gives me a list of ~55 allegedly modified
> >> > files, finishing up with:
> >> >
> >> >     pending merge tips: (use -v to see all merge revisions)
> >> >       Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by 
> >> > XSETTINGS...
> >> >
> >> > Would somebody please tell me what I might have done to make bzr think
> >> > I've got 55 modified files?  How might I recover from this?
> >>
> >> The "pending merge" message means that in the past (before you made the
> >> quick fix to the two files) you did:
> >>
> >>     bzr merge
> >>
> >> This pulled stuff from the local trunk branch, and merged it with your
> >> local quickfixes branch.  But you have to also run "bzr commit" to
> >> complete the fix.  You didn't at the time, so the quickfixes branch
> >> remains in a "the merge has locally finished but it is uncommitted"
> >> state.
> >
> > That's probably what happened.
> 
> 
> I do not understand. Can someone please explain to me why a bazaar
> user have to take care of this?

It's in the workflow described on the wiki: the process of merging a
branch with the mainline involves two commands:

  bzr merge
  bzr commit

The first one merges the text of the files, but does not combine their
histories.  The second command finishes the merging process by
updating the history so that it now includes both local commits and
whatever happened in the mainline since the last time you merged from
it.

Note that there could be conflicts reported by "bzr merge", in which
case you should resolve them manually, then use a 3rd command to tell
Bazaar that the conflicts were resolved:

  bzr resolve file1 file2 file3 ...

where the named files are those where you resolved the conflicts.
This 3rd command should come between "bzr merge" (which reports the
conflicts in the first place) and "bzr commit".

These complications are the reason why IMO using a separate branch for
``quick fixes'' is not the best way.  Doing such simple changes
directly in the trunk, or in a separate branch that is bound to the
remote repository, is much better.  The latest version of
BzrForEmacsDevs page on the wiki suggest these latter 2 possibilities,
but Alan is using the previous suggestion, whereby the quickfixes
branch was a local branch with the trunk mirror its parent.

The workflow with a local branch whose parent is the trunk mirror is
IMO better suited to working on a non-trivial set of changes or a new
feature.  That's because this kind of job is probably not finished in
one go, and you need to return to it in the course of several days or
even weeks.  So you will want to be isolated from changes on the trunk
for a while.  Also, separating feature development into a separate
branch will allow you to make simple unrelated changes on the trunk at
the same time, without having your local changes get in your way.

With such a significant development branch, the overhead of merging
from the trunk from time to time is justified.  With simple changes,
it is not, IMO.