bzr update produces strange conflicts in a bound branch with local commits

Bug #236724 reported by Alexey Borzenkov
This bug report is a duplicate of:  Bug #113809: update performs two merges. Edit Remove
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Low
Unassigned

Bug Description

Steps to reproduce:

$ bzr init proj1
$ cd proj1
create a file my1.txt, with any text
$ bzr add
$ bzr commit -m "initial commit"
$ cd ..
$ bzr checkout proj1 proj2
$ cd proj2
create a file my2.txt, with several lines of text
$ bzr add
$ bzr commit --local -m "a work is under way"
rewrite my2.txt completely, no line should be same
$ bzr commit -m "finished the work"

After this you will see strange conflicts for my2.txt. It could be avoided if I commited my changes locally before doing an update, but now it seems too late.

Additionally, if I run

$ bzr remerge --weave

It seems to do the job (though I'm not sure), however it throws an exception:

Exception exceptions.AttributeError: "'WorkingTree4' object has no attribute 'repository'" in <generator object at 0x016A8918> ignored
bzr: ERROR: The file id "my2.txt-20080602082447-bcnk2tqokm95i6jm-1" is not present in the tree <Inventory object at 16ab030, contents={'my1.txt-20080602080252-cc93rsro6uk2gy9d-1': InventoryFile('my1.txt-20080602080252-cc93rsro6uk2gy9d-1', u'my1.txt', parent_id='TREE_ROOT', sha1='b80494bb5b855289c7873d076ab7b30445c1748e', len=19), 'TREE_ROOT': InventoryDirectory('TREE_ROOT', u'', parent_id=None, <email address hidden>')}>.

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Perhaps the resolution could be to disallow bzr update when you have uncommited changes to the files you have changed in local commits?

Revision history for this message
James Westby (james-w) wrote :

Hi,

I'm not really sure that I understand what is causing this,
but the outcome is definitely not optimal.

The update leaves you with:

added:
  b
unknown:
  b.BASE
  b.OTHER
  b.THIS
conflicts:
  Contents conflict in b
  Text conflict in b
  Path conflict: b.THIS / b
pending merges:
  James Westby 2008-06-16 b

where b is the file added in the checkout.

Does this mean that the file-id differs if the is a path conflict?
That would seem odd to me.

Thanks,

James

Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
importance: Medium → Low
Revision history for this message
Alexey Borzenkov (snaury) wrote :

I don't know as well. I've seen another similar bug report, although there was a slightly different problem (it was also conflicting on .BASE, .OTHER and .THIS files, creating lots of hard-to-resolve conflicts), but then got distracted and can't find it anymore. It was something along the lines of "bzr update merges changes twice".

Revision history for this message
James Westby (james-w) wrote :

Hi,

I've just touched bug 228506 which mentions these files, is that
the one that you were thinking of?

Thanks,

James

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Too much time passed, and that's all I can find now too, so it must be my mind playing tricks with me. So I assume my bug would be about wrong behavior of bzr update. An interesting observation: if I shelve changes before doing an update, then update, then unshelve and commit there are no conflicts.

Revision history for this message
Matthew Fuller (fullermd) wrote : Re: [Bug 236724] Re: [bzr-1.5] bzr update produces strange conflicts in a bound branch with local commits

> I've just touched bug 228506 which mentions these files, is that
> the one that you were thinking of?

Perhaps bug 113809? I have a script to reproduce in comments.

--
Matthew Fuller
<email address hidden>

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Oh! Yes, bug 113809 is exactly what I was thinking of. So my mind wasn't tricking me after all. :) Are these bugs the same issue here?

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

Other bug subscribers

Remote bug watches

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