Merge lp:~gz/bzr/conflicts_non_ascii_ui_686161 into lp:bzr
Status: | Merged |
---|---|
Approved by: | John A Meinel |
Approved revision: | no longer in the source branch. |
Merged at revision: | 5907 |
Proposed branch: | lp:~gz/bzr/conflicts_non_ascii_ui_686161 |
Merge into: | lp:bzr |
Prerequisite: | lp:~gz/bzr/trivial_refactor_conflict_stanza_tests |
Diff against target: |
256 lines (+83/-25) 8 files modified
bzrlib/conflicts.py (+4/-4) bzrlib/merge.py (+1/-1) bzrlib/status.py (+1/-1) bzrlib/tests/blackbox/test_conflicts.py (+58/-14) bzrlib/tests/test_conflicts.py (+13/-2) bzrlib/tests/test_transform.py (+1/-1) bzrlib/transform.py (+2/-2) doc/en/release-notes/bzr-2.4.txt (+3/-0) |
To merge this branch: | bzr merge lp:~gz/bzr/conflicts_non_ascii_ui_686161 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
John A Meinel | Approve | ||
Review via email:
|
Commit message
Fix unicode handling in bzrlib.conflicts ui code
Description of the change
Conflict objects contain paths, which are unicode, but the conflicts ui calls str() on them which only works for ascii paths.
This branch adds tests that cover the Conflict stringifying code, and changes str() calls. Note, despite changing the __str__ method to __unicode__ this won't protect other callers from doing the wrong thing. Anyone currently using str() will continue to work in the ascii case and continue to fail in the non-ascii case due to the joys of Python string logic.
A particularly fun gotcha was the per-conflict tests actually passed regardless, because of this:
>>> class U(object):
... def __str__(self):
... return u"\xa7"
...
>>> unicode(U())
u'\xa7'
>>> str(U())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa7' in position 0: ordinal not in range(128)
Forgot to mention: TestUnicodePath sOnAsciiTermina l is currently skipped because the ui code doesn't decide what to do in this case yet apparently. That's really another issue so this fix shouldn't depend on that being resolved.