Bazaar

`bzr resolve --take-other` crashed in 2.2.1

Bug #653031 reported by Alexander Belchenko
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
High
Unassigned

Bug Description

After local push from one branch to another I have a conflict. I've decided to test new --take-other feature. Unfortunately it does not work.

C:\work\Schemes\ACD\MainControl>bzr resolve main_control.opj --take-other
bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'lower'

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 912, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1112, in run_bzr
  File "bzrlib\commands.pyo", line 690, in run_argv_aliases
  File "bzrlib\commands.pyo", line 705, in run
  File "bzrlib\cleanup.pyo", line 135, in run_simple
  File "bzrlib\cleanup.pyo", line 165, in _do_with_cleanups
  File "bzrlib\conflicts.pyo", line 160, in run
  File "bzrlib\conflicts.pyo", line 189, in resolve
  File "bzrlib\conflicts.pyo", line 415, in _do
  File "bzrlib\conflicts.pyo", line 549, in action_take_other
  File "bzrlib\conflicts.pyo", line 444, in _resolve_with_cleanups
  File "bzrlib\cleanup.pyo", line 135, in run_simple
  File "bzrlib\cleanup.pyo", line 165, in _do_with_cleanups
  File "bzrlib\conflicts.pyo", line 508, in _resolve
  File "bzrlib\transform.pyo", line 1544, in apply
  File "bzrlib\transform.pyo", line 510, in _check_malformed
  File "bzrlib\transform.pyo", line 501, in find_conflicts
  File "bzrlib\transform.pyo", line 650, in _duplicate_entries
AttributeError: 'NoneType' object has no attribute 'lower'

bzr 2.2.1 on python 2.6.4 (Windows-XP-5.1.2600-SP3)
arguments: ['C:\\Program Files\\Bazaar\\bzr.EXE', 'resolve', 'main_control.opj', '--take-other']
encoding: 'cp1251', fsenc: 'mbcs', lang: None
plugins:
  acad C:\work\Bazaar\plugins\acad [0.8.0]
  bzrtools C:\Program Files\Bazaar\plugins\bzrtools [2.2.0]
  colo C:\work\Bazaar\plugins\colo [0.2.0dev]
  explorer C:\work\Bazaar\plugins\explorer [1.1.1dev]
  format1 C:\work\Bazaar\plugins\format1 [unknown]
  kftp C:\work\Bazaar\plugins\kftp [unknown]
  launchpad C:\Program Files\Bazaar\plugins\launchpad [2.2.1]
  qbzr C:\work\Bazaar\plugins\qbzr [0.19.2]
  rewrite C:\Program Files\Bazaar\plugins\rewrite [0.6.1]
  scmproj C:\work\Bazaar\plugins\scmproj [0.6.1]
  x_bit C:\work\Bazaar\plugins\x_bit [1.0.0]

*** Bazaar has encountered an internal error. This probably indicates a
    bug in Bazaar. You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

Revision history for this message
Alexander Belchenko (bialix) wrote :

Of course I could use `bzr revert` instead in this case, but traceback is soooooo ugly thing.

Martin Pool (mbp)
tags: added: conflicts resolve treetransform
Revision history for this message
Vincent Ladeuil (vila) wrote :

Sorry it took so long to answer but... do you have a reproducing recipe for that ?

This looks like a tricky case where we expect an entry to have a name but ends up with None instead which should be detected long before in the call stack :-/

Revision history for this message
Vincent Ladeuil (vila) wrote :

Or was it just a typo in 'main_control.opj ': 'opj' instead of 'obj' ?

Revision history for this message
Alexander Belchenko (bialix) wrote :

It's not a typo.

Revision history for this message
Alexander Belchenko (bialix) wrote :

I don't have an exact reporoduce receipe, and it was month ago, so I don't remember all details. But I think the steps should be:

* you have 1st branch with uncommitted changes (I'm not sure for 100% though) and 2nd branch with committed diverged changes;
* push from 2nd branch to 1st, got conflict
* go to 1st branch and run `bzr resolve --take-other`, got traceback

Revision history for this message
Vincent Ladeuil (vila) wrote :

Ok, so, I'm looking at bug #646961 which may or not be a duplicate of this one depending on: is main_control.opj a text file that was involved in a text conflict or was it involved in a path conflict instead ?

It's a dupe it's the former.

Revision history for this message
Alexander Belchenko (bialix) wrote : Re: [Bug 653031] Re: `bzr resolve --take-other` crashed in 2.2.1

Vincent Ladeuil пишет:
> Ok, so, I'm looking at bug #646961 which may or not be a duplicate of
> this one depending on: is main_control.opj a text file that was involved
> in a text conflict or was it involved in a path conflict instead ?
>
> It's a dupe it's the former.

main_control.opj is the text xml-like file. qdiff shows the changes
for it as for the text file, therefore its content has no null bytes
at all.

Revision history for this message
Alexander Belchenko (bialix) wrote :

Looking at the traceback of the other bug I think this one is the dupe of that one.

Revision history for this message
Vincent Ladeuil (vila) wrote :

Thanks for confirming, I'll mark it as a dupe.

The root issue here is that --take-this and --take-other are *not* implemented (yet) for text conflicts but the implementation inherits from another kind of conflict which is totally irrelevant :(

I'm working on a fix.

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.