Possibly ignorable test failure?
Paul Moore
p.f.moore at gmail.com
Tue May 20 22:13:24 UTC 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