Bazaar

suggested update when bound branch is out of date does confusing things

Bug #175589 reported by Colin Watson
This bug report is a duplicate of:  Bug #113809: update performs two merges. Edit Remove
8
Affects Status Importance Assigned to Milestone
Bazaar
Incomplete
Undecided
Unassigned

Bug Description

I found a local branch that I hadn't bound to its mirror on Launchpad as I'd intended, so I used 'bzr bind' on it, and then went to commit my local changes:

<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm/partman-auto-lvm>$ debcommit
bzr commit -m '* Add Vcs-Bzr for Ubuntu.'
bzr: ERROR: Bound branch BzrBranch5('file:///home/cjwatson/src/ubuntu/partman-auto-lvm/partman-auto-lvm/') is out of date with master branch RemoteBranch(bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/partman-auto-lvm/ubuntu/).
To commit to master branch, run update and then commit.
You can also pass --local to commit to continue working disconnected.
debcommit: commit failed

Hmm, OK, fair enough. Normally I'd use 'bzr push' in this situation, which of course works fine, but in this case I decide that I'll do as it says and see what happens.

<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm/partman-auto-lvm>$ bzr up
 M auto-lvm_tools.sh
 M debian/changelog
 M debian/control
 M debian/po/eu.po
Text conflict in debian/changelog
1 conflicts encountered.
 M auto-lvm_tools.sh
 M debian/changelog
 M debian/control
 M debian/po/eu.po
Text conflict in debian/changelog
Conflict adding file debian/changelog.BASE. Moved existing file to debian/changelog.BASE.moved.
Conflict adding file debian/changelog.OTHER. Moved existing file to debian/changelog.OTHER.moved.
Conflict adding file debian/changelog.THIS. Moved existing file to debian/changelog.THIS.moved.
4 conflicts encountered.
Updated to revision 193.
Your local commits will now show as pending merges with 'bzr status', and can be committed with 'bzr commit'.
<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm/partman-auto-lvm>$ bzr st
modified:
  auto-lvm_tools.sh
  debian/changelog
  debian/control
  debian/po/eu.po
unknown:
  debian/changelog.BASE
  debian/changelog.BASE.moved
  debian/changelog.OTHER
  debian/changelog.OTHER.moved
  debian/changelog.THIS
  debian/changelog.THIS.moved
conflicts:
  Text conflict in debian/changelog
  Conflict adding file debian/changelog.BASE. Moved existing file to debian/changelog.BASE.moved.
  Conflict adding file debian/changelog.OTHER. Moved existing file to debian/changelog.OTHER.moved.
  Conflict adding file debian/changelog.THIS. Moved existing file to debian/changelog.THIS.moved.
pending merges:
  Colin Watson 2007-05-10 releasing version 23ubuntu1
    Colin Watson 2007-05-10 merge from Debian 23
    fjp 2007-04-26 releasing version 23
    bubulle 2007-04-13 [l10n] [SILENT_COMMIT] Synchronising with translation files from packages/po
    alphix-guest 2007-03-18 Pass the device as an explicit argument to wipe_disk

Whoa. Those are the changes that I had in my local branch. Given that the local branch was a direct linear descendant of the remote branch, why didn't it just DWIM and push these changes rather than doing this confusing thing? I don't want these to show up as a merge in my history, and, given that I already released this version to archive.ubuntu.com, I don't want to go trying to resolve the conflicts that bzr has sprayed over my tree at this point either.

I recovered by fishing the correct revision id out of .bzr/repository/revisions.knit and then doing:

<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm/partman-auto-lvm>$ cd ..
<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm>$ mv partman-auto-lvm bust
<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm>$ bzr branch -rrevid:<email address hidden> bust partman-auto-lvm
Branched 195 revision(s).
<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm>$ cd partman-auto-lvm
<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm/partman-auto-lvm>$ bzr push bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/partman-auto-lvm/ubuntu/
Pushed up to revision 195.
<cjwatson@sarantium ~/src/ubuntu/partman-auto-lvm/partman-auto-lvm>$ bzr bind bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/partman-auto-lvm/ubuntu/

... but this is not exactly obvious or intuitive. I suggest that either (a) update be made to do something more intelligent in this situation or (b) the documentation be corrected to suggest that push might also be a useful thing to do. I'd prefer option (a).

Revision history for this message
John A Meinel (jameinel) wrote :

I think this is just a symptom of bug #113809. Should this be marked as a duplicate?

Changed in bzr:
status: New → Incomplete
Revision history for this message
Wouter van Heyst (larstiq) wrote :

Bug #113809 is part of it, but imho that is not the main cause (and thus no duplicate).

That `bzr update` in a checkout which hasn't diverged, just has extra revisions, pivots the local revisions away contradicts what I'd expect to happen. That the pivot requires merges, combined with uncommitted changes and #113809 does then also mess up your working tree.

I know the pivot behaviour of update has been discussed in the past, but I can't find a bug for it now.

I emulate the behaviour after the fact with:

  bzr heads --dead
  bzr pull . -r revid:<relevant head>

Unfortunately `bzr st -v --show-ids` doesn't give me the revision ids of merged revisions, that is where heads comes in.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 175589] Re: suggested update when bound branch is out of date does confusing things

On Sun, 2009-04-05 at 13:32 +0000, Wouter van Heyst wrote:
> Bug #113809 is part of it, but imho that is not the main cause (and thus
> no duplicate).
>
> That `bzr update` in a checkout which hasn't diverged, just has extra
> revisions, pivots the local revisions away contradicts what I'd expect
> to happen. That the pivot requires merges, combined with uncommitted
> changes and #113809 does then also mess up your working tree.
>
> I know the pivot behaviour of update has been discussed in the past, but
> I can't find a bug for it now.

Here is the contract for update (light and heavy):
'update prepares you to commit to the branch after doing some
uncommitted work'.
Implications->
'update && revert' -> now the same as the branch
'update && commit' -> your local work is now on the branch.

-Rob

Revision history for this message
Stavros Korokithakis (stavrosk) wrote :

Try this:

commit to a bound branch
do some work
commit --local
do some work
update
your work has produced conflicts, even though the master branch is a strict subset of your local branch. Conflicts should not have been produced, and, ideally, bzr should have pushed your changes upstream without requiring you to commit again...

Revision history for this message
Wouter van Heyst (larstiq) wrote : Re: [Bug 175589] Re: suggested update when bound branch is out of date does confusing things

On Sun, Apr 05, 2009 at 09:23:19PM -0000, Robert Collins wrote:
> On Sun, 2009-04-05 at 13:32 +0000, Wouter van Heyst wrote:
> > Bug #113809 is part of it, but imho that is not the main cause (and thus
> > no duplicate).
> >
> > That `bzr update` in a checkout which hasn't diverged, just has extra
> > revisions, pivots the local revisions away contradicts what I'd expect
> > to happen. That the pivot requires merges, combined with uncommitted
> > changes and #113809 does then also mess up your working tree.
> >
> > I know the pivot behaviour of update has been discussed in the past, but
> > I can't find a bug for it now.
>
> Here is the contract for update (light and heavy):
> 'update prepares you to commit to the branch after doing some
> uncommitted work'.
> Implications->
> 'update && revert' -> now the same as the branch
> 'update && commit' -> your local work is now on the branch.

That's a nice property, but it also amounts to a _really_ nasty spot in
our UI that makes it hard to do what many people expect.

Wouter van Heyst

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.