On May 29, 2008, at 8:02 PM- May 29, 2008, David Glasser wrote:
> On Thu, May 29, 2008 at 6:53 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> David Glasser wrote:
>>>
>>> On Thu, May 29, 2008 at 5:52 AM, C. Michael Pilato
>>> <cmpilato_at_red-bean.com> wrote:
>>>>
>>>> David Glasser wrote:
>>>>>
>>>>> On Wed, May 28, 2008 at 11:42 PM, Stefan Küng <tortoisesvn_at_gmail.com
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>> David Glasser wrote:
>>>>>>>
>>>>>>> I can reproduce this with 1.4.x svnserve but not trunk svnserve.
>>>>>>>
>>>>>>> Note that the actual over-the-wire communication seems
>>>>>>> identical,
>>>>>>> which is kind of wacky. But maybe the lack of depth
>>>>>>> capability is
>>>>>>> triggering some compat code, which is broken?
>>>>>>
>>>>>> Finally got the svn.exe built here.
>>>>>> I can reproduce the problem from here too (on XP SP3) with
>>>>>> svn.exe
>>>>>> built
>>>>>> from the 1.5.x branch.
>>>>>>
>>>>>> Since you already got a reproduction recipe, I'm not trying to
>>>>>> create
>>>>>> another one. But just as an additional info: my repository is on
>>>>>> apache,
>>>>>> not
>>>>>> svnserve (svn version 1.4.6 on the apache server). So it's
>>>>>> nothing to
>>>>>> do
>>>>>> with svnserve.
>>>>>
>>>>> The same problem code is in all three remote ra layers. This
>>>>> fixes
>>>>> the issue; currently running tests to see if it does any harm.
>>>>>
>>>>> cmpilato, any insight into why you wrote the code this way
>>>>> originally?
>>>>
>>>> Sorry, I have no memory of writing this code at this point. (I
>>>> mean,
>>>> besides knowing that I was the one who wrote it.) There's some
>>>> chance it
>>>> was a botched logic reduction (that code might have at some point
>>>> been
>>>> "if
>>>> dir and some condition or if file and some other condition").
>>>>
>>>> Anyway, the tweak to okay_to_edit() looks correct.
>>>>
>>>>> (Also, why libsvn_ra_svn/client.c(ra_svn_get_reporter) uses
>>>>> svn_error_clear in its call to svn_delta_depth_filter_editor?)
>>>>
>>>> Ooh. I probably deferred the change to ra_svn_get_reporter() to
>>>> return
>>>> an
>>>> error (and its callers to expect it) because I was just trying to
>>>> get
>>>> something coded up, and failed to go back and correct that before
>>>> committing
>>>> up.
>>>
>>> Mike and I talked a little on IRC, and it sounds like we're good to
>>> commit that. I committed it in r31516, along with a test. I will
>>> nominate it for backport to 1.5.0, though I'd understand if the
>>> not-a-regression (since it's a new flag) lets people wait until
>>> 1.5.1.
>>> (But it is mostly-undetectable wc corruption...)
>>
>> To somebody unfamiliar with the code, WC corruption sounds pretty
>> serious.
>> Do you expect people to run into this often, or only rarely?
>
> The scenario that would produce this would be:
>
> (a) Download brand-spanking new 1.5.0.
>
> (b) Use it with the server you already have.
>
> (c) Notice there is a new depth feature.
>
> (d) Start playing around with depth.
>
> (e) Run 'svn up --depth=empty FILE' even though it ought to be
> completely equivalent to 'svn up FILE', because you're experimenting
> with the exciting new feature.
>
> (Also, it was triggered by some TortoiseSVN feature, but I think
> Stefan changed his code to work around this?)
>
i'd like to see an rc9 i think, this is going to be standard fare for
my users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-30 05:27:56 CEST