On Thu, Aug 15, 2013 at 12:12 PM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Philip Martin [mailto:philip.mar...@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.alva...@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
