test_nonascii: two unicode a's

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> Alexander Belchenko wrote:
>>> We discuss that test_contents_merge2 should be skipped on win32 because
>>> diff3 on win32 change line-endings. Attached patch fix this.
> 
> Well, if typical implementations of diff3 on win32 are broken, I think
> we should not permit merge-type diff3 on that platform at all.  The test
> failure indicates that, on win32, --merge-type diff3 really is broken.
> 
> Aaron

I agree with you. And I can also say that my cygwin implementation of
diff3 actually is doing the right thing. (The tests pass on my system).

I'm not 100% comfortable with skipping tests just because they might
fail, especially because of external factors (whether OS or an external
program).

Using 'bzr merge --merge-type=diff3' will potentially do bad things on
Alexander's system. It seems like he should be made aware of that, by
something like a test failure.

I'm wondering about augmenting the test suite with some sort of
more-helpful summary. So you run the test suite, and at the end you get:

failures = 0, errors = 0, limitations = 4
Platform Limitations:
   diff3 does not preserve line endings, exercise caution with
- --merge-type=diff3. Or install a diff3 which preserves line endings.
   Weave format branches cannot be opened twice. Cannot use 'bzr pull .'
style syntax. Upgrade to Knit format if this is desired.
   Weave format branches cannot handle file ids with '<>'. Upgrade to
Knit format if this is desired.

...

I don't know exactly the implementation or final output. But just
skipping tests because we want to have the test suite pass seems unclean
to me.
Essentially, you are lying to the user, telling them that there are no
problems, rather than actually telling them what limitations are present.

At the same time, having the test completely fail isn't 100% relevant
either, because in many cases, it isn't something the user should report
as a bug. Its known, and it may either be an explicit limitation we have
no control over (case-insensitivity), or something that we aren't fixing
(old formats not supporting X).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEqtGgJdeBCYSNAAMRAgUoAJwOv7yHBfYea6mCSSSbmKRNe+TeLQCeJu/B
5ZdEA9d/seBzFQ/v96YOOTU=
=/J5u
-----END PGP SIGNATURE-----