diff_tests 4 and wc-ng

[Greg Stein <gs...@gmail.com>]

Hyrum,

I tracked down the problem with diff_tests 4. Ugh.

At a high level, "svn diff" is not reporting the change in A/D/G/rho.
The diff simply returns. Yet it is *clearly* different.

Also: it happens sporadically.

Works for wc-1, fails for wc-ng.

The problem originates in svn_wc__text_modified_interal_p() in
wc/questions.c. During the diff process, this is called with
force_comparison==FALSE, so the entry values are examined to shortcut
the process. Under wc-ng, working_size == -1 so a size comparison is
not performed. And *sometimes* mtime == text_time (no modification!)
and other times mtime == (text_time + 1 second) which means "yup.
modified."

IOW, depending on what gets recorded for text_time, we may or may not
flag a difference. It *never* reaches the byte-for-bye comparison.

Under wc-1, the working_size is always valid, and the different file
sizes are properly detected. TODO: eliminate the size check and see if
wc-1 has a similar time race.


For wc-ng, there are two things to do:

1) get working_size to have a correct value (for entries compatibility)
2) track down the variance in text_time recording

I'm going to work on the wc-1 TODO, and part 2. If you could track why
working_size comes out as -1 in wc-ng, then we could nail this.

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1506663

Re: diff_tests 4 and wc-ng

[Greg Stein <gs...@gmail.com>]

On Wed, Apr 1, 2009 at 16:19, Erik Huelsmann <eh...@gmail.com> wrote:
> On Wed, Apr 1, 2009 at 4:02 PM, Greg Stein <gs...@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

Re: diff_tests 4 and wc-ng

[Erik Huelsmann <eh...@gmail.com>]

On Wed, Apr 1, 2009 at 4:02 PM, Greg Stein <gs...@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.


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.

> 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?

Bye,

Erik.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1507462

Re: diff_tests 4 and wc-ng

[Greg Stein <gs...@gmail.com>]

Re: diff_tests 4 and wc-ng

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

Glanced over the mail.  I'll be online in ~ an hour and will look at  
the issue then.

(Oh, and I've got an idea of why revert 17 is failing, too.  You're  
going to love this one...)

-Hyrum

On Apr 1, 2009, at 7:41 AM, Greg Stein wrote:

> Hyrum,
>
> I tracked down the problem with diff_tests 4. Ugh.
>
> At a high level, "svn diff" is not reporting the change in A/D/G/rho.
> The diff simply returns. Yet it is *clearly* different.
>
> Also: it happens sporadically.
>
> Works for wc-1, fails for wc-ng.
>
> The problem originates in svn_wc__text_modified_interal_p() in
> wc/questions.c. During the diff process, this is called with
> force_comparison==FALSE, so the entry values are examined to shortcut
> the process. Under wc-ng, working_size == -1 so a size comparison is
> not performed. And *sometimes* mtime == text_time (no modification!)
> and other times mtime == (text_time + 1 second) which means "yup.
> modified."
>
> IOW, depending on what gets recorded for text_time, we may or may not
> flag a difference. It *never* reaches the byte-for-bye comparison.
>
> Under wc-1, the working_size is always valid, and the different file
> sizes are properly detected. TODO: eliminate the size check and see if
> wc-1 has a similar time race.
>
>
> For wc-ng, there are two things to do:
>
> 1) get working_size to have a correct value (for entries  
> compatibility)
> 2) track down the variance in text_time recording
>
> I'm going to work on the wc-1 TODO, and part 2. If you could track why
> working_size comes out as -1 in wc-ng, then we could nail this.
>
> Cheers,
> -g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1506728