[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn up --depth empty breaks working copy

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Thu, 29 May 2008 18:53:40 -0700

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?

I'd really like to avoid another RC if possible, but if this is a
showstopper, then let's get it in.


Received on 2008-05-30 03:53:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.