On Wed, Apr 1, 2009 at 16:19, Erik Huelsmann <ehuels_at_gmail.com> wrote:
> On Wed, Apr 1, 2009 at 4:02 PM, Greg Stein <gstein_at_gmail.com> wrote:
>> From my investigation, it looked like we need to mark child nodes of a
>> copied subtree that is now schedule-delete as both schedule-delete and
>> copied. We were not marking them copied.
>>
>> In any case, I just confirmed the same text_time/mtime race in wc-1
>> when I disabled the size check. Eesh.
>
> Isn't this an issue because we have the "wait for timestamps" disabled
> when running the test suite? Under normal operation, you would not see
> the situation with "no time difference" because it would wait for
> timestamps.
Bert mentioned this on IRC just before your email.
I tracked down the right setting and now... the test suite isn't
failing for wc-1.
It will still fail for wc-ng until we store the size properly, but
that (essentially) to be expected.
> Basically, the test depends on the file size to be changed for the
> test to succeed. I don't think it's the only one.
Probably not. This particular design-point of the test suite isn't
really clear :-P
>> Basically: if altered the test to create a "new rho" with a file of
>> the *same length*, then it would sporadically fail, even within wc-1.
>> The human description would be "replace a file with something of the
>> same length; svn diff may not show any differences."
>
> But only if it has the same length *and* the same timestamp, right?
Right. And the sleep is to prevent the latter condition. Gotcha.
Tho I *am* wondering how we managed to get different values for the
text_time from the mtime. I would have expected text_time's value to
be whatever mtime fetched. Maybe (in this case) the text_time is
representing the BASE node rather than the newly-added file. That
would be stupid and wrong, but hey... that's wc-1 for you.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1507791
Received on 2009-04-01 17:02:29 CEST