Possibly ignorable test failure?

Paul Moore p.f.moore at gmail.com
Tue May 20 17:13:24 CDT 2008


2008/5/20 Dirkjan Ochtman <dirkjan at ochtman.nl>:
> Paul Moore <p.f.moore <at> gmail.com> writes:
>> I can fix this, but it involves writing a chunk of ugly
>> string-manipulation code (as none of the os.path functions give me a
>> way of doing this). The question is, should I do so? In my view, the
>> tests are incorrect, as they check for exact string matches of the
>> output, rather than working on functional equivalence, but that's the
>> way they are and I'm not about to change that. So should the core code
>> pay the cost (a small performance cost and a somewhat larger
>> maintainability cost) to keep the tests happy?
>
> I think in this case changing the test output would be just fine. If the paths
> are still correct (and in fact, closer to what Windows users are used to), that
> seems like an improvement to me, and certainly not reason to bloat the core.

Fair enough, but I don't know how to change the test output in a way
that doesn't break Unix. Consider:

$ hg add a/b
added a/b

On Windows, that would change to

$ hg add a/b
added a\b

but it has to stay the same on Unix. I don't think the test suite has
a way to handle OS-dependent changes in the expected output, does it?
The only way I can think to do that is to add to the Win32 test suite
patch series, and I'm not sure I know how to go about that :-( It's be
a pretty big change anyway, most reported filenames with directory
parts will need changing.

Maybe for now, I'll add the separator-preserving hackery, and try to
do so in a way that lets me easily remove it later, if a better option
becomes possible...

Paul.


More information about the Mercurial-devel mailing list