Re: svn up --depth empty breaks working copy

David Glasser wrote:
> On Wed, May 28, 2008 at 10:38 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>> David Glasser wrote:
>>> On Wed, May 28, 2008 at 10:07 PM, Stefan Küng <tortoisesvn_at_gmail.com>
>>> wrote:
>>>> David Glasser wrote:
>>>>> On Wed, May 28, 2008 at 1:44 PM, Stefan Küng <tortoisesvn_at_gmail.com>
>>>>> wrote:
>>>>>> On Wed, May 28, 2008 at 10:33 PM, Stefan Küng <tortoisesvn_at_gmail.com>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Using a build from the 1.5.x branch of svn (built about 4 hours ago)
>>>>>>> on
>>>>>>> Windows Vista, repository on apache 2.0, svn 1.4.6, Windows Vista:
>>>>>>>
>>>>>>> $ svn co https://server/repo/test/trunk testwc
>>>>>>> $ cd testwc
>>>>>>> $ svn up -r1 file --depth empty
>>>>>>> At revision 1.
>>>>>>> $ svn up
>>>>>>> svn: Checksum mismatch for 'file'; expected: '....', actual: '....'
>>>>>>>
>>>>>>>
>>>>>>> The same sequence appears to work with file:/// access instead of
>>>>>>> https.
>>>>>> Ups: forgot to mention that the file must have the svn:needs-lock
>>>>>> property set (and therefore be readonly).
>>>>> Do you know if this is related to the TSVN issue reported recently
>>>>> here with updating locked files?
>>>> Yes. I finally found a way to reproduce the issue reported on the TSVN
>>>> list
>>>> with the command line client so I'm reporting it here.
>>>>
>>>>> Also, does it occur with 1.5.x servers or only with old servers?
>>>> I'm sorry, but I don't have an 1.5.x server ready here to test. Maybe
>>>> someone else has one ready and can try the above sequence and see if it
>>>> happens there too?
>>> I'm working on it. A more complete recipe would be nice though; for
>>> example, in what revision is the svn:needs-lock property set? (In r1?
>>> After r1? In the revision that is checked out originally or an
>>> earlier one? Is it unset later?)
>> In my tests and attempts to reproduce the problem with the CL client, I
>> tried different files first without success.
>> Then I set the svn:needs-lock property on one, committed and updated (so the
>> file was made readonly).
>> After that, the problem occurred just by updating to any earlier revision
>> with --depth empty.
>> Since the working copy is broken after the update to HEAD (actually, it's
>> already broken after the first update because the content of the file does
>> not get updated), I couldn't unset the svn:needs-lock property later.
>>
>> In my test repository, the file actually had several revisions. I've set the
>> svn:needs-lock on it in r9 (HEAD at the time), committed and updated.
>>
>> Hope this helps a little.
>
> OK. And to confirm: you aimed the update to depth-empty at the file
> (which is sort of meaningless anyway, no?), and you were updating to a
> revision where the file did already exist (but was not needs-lock)?

Yes, exactly.
I know that depth-empty is sort of meaningless (depending on how you
understand the docs). Depth-empty as far as I understand it is "this
item only", and should be the same as depth-file for files.
That's why I passed depth-empty to the svn_client_update() call in TSVN
when I updated a file which failed to lock due to the file being out of
date. I've changed that now to depth-files, but I think the working copy
should not break because of that.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net