Reporting "nearly-exact" adds (Was: Windows test suite state)

[Adrian Buehlmann]

On 05.06.2008 14:26, Paul Moore wrote:
> But as it's solely a reporting issue which only occurs on Windows, and
> Windows users are used to more verbose commands, it may not be worth
> fixing (although fixing the tests will be necessary - redirecting the
> output to null should be enough, though).

I don't like the idea of having significantly different output on Windows
compared to unixes (like, for example additional lines in output on
Windows).

Of course, we already have *minor* differences Windows <-> unix with current
Mercurial (for example "\" instead of "/" on paths output by hg status).

But additional output lines on Windows that do not exist on unix for
the specific same invocation (and same precondition) is bad.

But I admit, I don't have an idea right now how to fix that aspect
of your pending patch series (and I am eager myself to get your
patch series in).

As I understand it, current unwanted example behavior on Windows
with your patches is:

> hg add x\a.txt
adding x\a.txt

and

> hg add x/a.txt
adding x\a.txt

which should output nothing (current pristine behavior).

So, is it only hg add that's wrong?

If yes, are there any other hg add call patterns that output
unwanted additional line?

What I don't know is why it needs a matcher to detect that
case.

Wouldn't it be correct to say *if* there are file arguments
on the command line, then there must be no "adding" output lines?
Wouldn't that case be simple to detect? So that info could
be transferred with a flag parameter down the chain of
function calls?

I admit I'm rather unfamiliar with the code.