Re: Help me unstick my bzr, please.

[Giorgos Keramidas <keramida@ceid.upatras.gr>]

On Sat, 16 Jan 2010 21:38:21 +0000, Alan Mackenzie <acm@muc.de> wrote:
> On Sat, Jan 16, 2010 at 04:37:24AM +0200, Giorgos Keramidas wrote:
>> On Fri, 15 Jan 2010 22:27:24 +0000, Alan Mackenzie <acm@muc.de> 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
>
> OK, that's quite likely.  Am I right believing that 'bzr merge' pulls in
> any changes in the current branch's parent?

Hi Alan,

Yes, you are right.  "bzr merge" pulls changes from the parent branch.
This means that if you have committed local changes in 'quickfixes', the
history DAG of the quickfixes branch looks like this:

    ... o --- o --- o --- X (local change)
                     \
                      `----- o --- o --- Y (last parent branch changeset)

After "bzr merge" has pulled the changes at the bottom of this history
DAG it then tries to merge these changes with the state of the current
working directory.

The final result of a successful "bzr merge" command is then a working
directory that refers to _both_ the parent changes (your "X" local
change and the latest changeset in the parent branch (Y in this case).

Before you "bzr commit" a merged state the history DAG is

    ... o --- o --- o --- X =================== W
                     \                         //
                      `----- o --- o --- Y ===//

where the double lines represent the uncommitted state of the "merge"
you just performed.  This merge is *not* recorded into the metadata of
the branch yet, so you have to follow "bzr merge" with "bzr commit" to
complete this operation:

    ... o --- o --- o --- X ------------------- W
                     \                         /
                      `----- o --- o --- Y ---/

This will record the locally merged files as a new changeset and you
will be able to "bzr push" to the parent branch.  The "bzr push" will
then be able to send the X and W changesets to the parent branch.

In terms similar to what CVS does, the two commands -- "bzr merge" and
"bzr commit" --- perform operations similar to "cvs update" and "cvs
commit".

  * The "bzr merge" command pulls changes from the parent branch, stores
    them in the .bzr metadata of the local branch and also tries to
    apply the changes it just pulled to the files of the working
    directory.  Conflicts may arise at this point, precisely as they did
    for "cvs update".

  * When all conflicts are resolved, "bzr commit" stores the resolved
    state of all files in the .bzr/ area of the local branch.  A "push"
    can then send them to the parent branch.

>> I think the easiest way to revert your local "quickfixes" branch to a
>> known & sane state is something like:
>>
>>     1. Keep a backup of the two files you modified.
>>     2. Wipe the local quickfixes branch.
>>     3. Re-create the quickfixes from trunk.
>>     4. Overwre the two files in the new quickfixes branch.
>>     5. Use "bzr diff" to inspect the changes.
>>     6. Commit them with "bzr commit".
>
> Do I want to revert it?  I don't think I do.  If I just do "bzr
> commit" in my .../quickfixes, that should leave it in a consistent
> state, shouldn't it?
>
> After that, I want to get my changes from .../quickfixes copied over
> to .../trunk.  Is 'bzr push' the way to do this?

The choice of "revert" was a poor one.  I didn't mean "revert" as in
"lose your local changes to the two files you edited manually, but more
like "finish the pending merge and allow more commits to this branch".

Stephen J. Turnbull has posted an easier method for restoring sanity to
the quickfixes branch, using "bzr shelve".  Now that I have read about
it and tried it in a small sample branch at home, I think it's probably
better to avoid trashing the quickfixes branch and use Stephen's
recommendation.