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

Re: svn 1.8 causing locks to be broken on update

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 15 Aug 2013 13:03:11 +0200

On Thu, Aug 15, 2013 at 12:12 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
>> Sent: donderdag 15 augustus 2013 11:41
>> To: Felipe Alvarez
>> Cc: Hiroharu Tamaru; Users Subversion Apache; Johan Corveleyn; William
>> Smith
>> Subject: Re: svn 1.8 causing locks to be broken on update
>>
>> Felipe Alvarez <felipe.alvarez_at_gmail.com> writes:
>>
>> >> I'm using a 1.8.x client and a 1.6.x server and I can't reproduce it. I
>> >> tried this
>> >>
>> >> svnadmin create repo --compatible-version 1.6
>> >> svn co http://localhost:8888/obj/repo wc
>> >> svn mkdir --parents wc/A/B/C
>> >> touch wc/A/B/C/f
>> >> svn add wc/A/B/C/f
>> >> svn ci -mm wc
>> >> svn up wc
>> >> svn lock wc/A/B/C/f
>> >> cd wc/A
>> >> svn up
>> >> cd ..
>> >> svn up
>> >> cd ..
>> >> svn st wc
>> >>
>> >> and the final status shows wc/A/B/C/f still locked.
>> >>
>> >> --
>> >> Philip Martin | Subversion Committer
>> >> WANdisco // *Non-Stop Data*
>> >>
>> > Hi Philip
>> >
>> > Pardon my ignorance. We are using an authentic 1.6.15 client, not a 1.8.1
>> > in 1.6 "mode" (If I am interpreting your --compatible-version option
>> > correctly). Further, we are using Apache 2.2 with the following config <
>> > http://pastebin.com/ZefLnHA9>
>> >
>> > We followed the exact same steps as you have, but not localhost, we used
>> a
>> > remote host. Should it matter?
>>
>> I have determined that the the lock gets broken when I use a 1.6.16
>> server but it is not broken when I use a 1.6.17 server. It was fixed by
>> r1124173.
>
> Ah, good catch:
> [[
> r1104309 | cmpilato | 2011-05-17 17:02:05 +0200 (di, 17 mei 2011) | 20 lines
>
> With rhuijben, avoid transmitting entry props for unmodified, locked
> files when the client-provided lock token matches what is stored in
> the repository. This fixes issue #3525 ("Locked file which is
> scheduled for delete causes tree conflict") and issue #3471 ("svn up
> touches file w/ lock & svn:keywords property").
>
> NOTE: There is a remaining 3525-related test that is still failing
> (update_tests.py 53), but that's because of out-of-date expectations
> in the WC-NG world. (That will be fixed in a subsequent revision.)
>
> * subversion/libsvn_repos/reporter.c
> (update_entry): Return early not only when there's not a provided
> lock token, but also when there's a provided lock token that matches
> what's in the repository.
>
> * subversion/tests/cmdline/lock_tests.py
> (update_locked_deleted): Remove @XFail decorator.
>
> * subversion/tests/cmdline/update_tests.py
> (update_with_file_lock_and_keywords_property_set): Remove @XFail decorator.
> ]]
>
> A group effort on 2011's SvnDay Hackathon :)
>
> Bert
>

Great! I remember that series of lock-related discussions / fixes.

Now, playing "user's advocate": is there still something useful to do
here? I.e. apparently ra_neon worked fine with the broken servers.
Should ra_serf also be able to handle this, so 1.8 clients can still
work fine with servers < 1.6.17?

-- 
Johan
Received on 2013-08-15 13:04:03 CEST

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

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