Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D497D5A.7000403@free.fr>
Date: Wed, 02 Feb 2011 16:50:50 +0100
From: OBones <obones@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11
MIME-Version: 1.0
To: Neil Bird <neil@jibbyjobby.co.uk>, users@subversion.apache.org
Subject: Re: Checkout really slow in Windows with lots of files in one
 directory
References: <4D402FA4.4020607@jibbyjobby.co.uk>
 <AANLkTinCzLKz7PJe3yutvhewP0JyyMV58TMaB8RvZSe+@mail.gmail.com>
 <4D497276.8030901@jibbyjobby.co.uk> <4D497447.7070502@free.fr>
 <20110202154002.GH2120@ted.stsp.name>
In-Reply-To: <20110202154002.GH2120@ted.stsp.name>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Sperling wrote:
> On Wed, Feb 02, 2011 at 04:12:07PM +0100, OBones wrote:
>    
>> Neil Bird wrote:
>>      
>>>   I couldn't use the version from trunk/1.7 as it differs too
>>> much.  I will try to submit the patch for someone's perusal at
>>> some point, but I couldn't properly test is as for some reason my
>>> build of svn out of 1.6.x svn (even before modifying it) fails
>>> 'make check':  all the tests pass, but I get a load of XFAIL lines
>>> I don't understand.
>>>
>>>   AFAICT, the XFAILs I get after my patch are the same as before,
>>> but it's not the warm PASS feeling I was hoping for.
>>>        
>> XFAIL stands for "eXpected to FAIL", meaning that if SVN is doing
>> good, then the test should fail.
>> For instance, you expect svn not to delete an existing file on
>> checkout, so you write your test expecting it to fail the checkout.
>> If it succeeds, the test has not failed as expected.
>>      
> That's not quite right. Behaviour like that would be verified
> via a PASS test. The test would FAIL if svn overwrote the file.
>
> XFails are used to flag known bugs or undesirable behaviour which
> cannot be fixed at present (e.g. there are a couple of XFAIL tests
> for tree conflict handling -- we'd like to do better, but can't at the
> moment).  Once the bug is fixed, the test will XPASS (unexpected PASS),
> and we switch it to PASS then.
>
>    
Ah that makes even more sense this way, thanks for the clarification