You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Felipe Alvarez <fe...@gmail.com> on 2013/08/04 06:41:43 UTC
svn 1.8 causing locks to be broken on update
I
'm using tortoiseSVN, and noticed that when updating the very root of the
repository, locks which I have taken under it become broken. Here is output
from cygwin.
---begin-output---
$ svn --version
svn, version 1.8.1 (r1503906)
compiled Jul 22 2013, 19:58:17 on x86-microsoft-windows
Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using
serf.
- handles 'http' scheme
- handles 'https' scheme
Felipe@FELIPES ~
$ cd ~/SVN/Trunk/Lettus/lbin
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ ls
backup.cron*
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ svn st
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ svn lock backup.cron
svn: warning: W160035: Path '/Trunk/Lettus/lbin/backup.cron' is already
locked by user 'felipe' in filesystem '/u3/SVN_Repository/db'
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ svn lock --force backup.cron
'backup.cron' locked by user 'felipe'.
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ svn st
K backup.cron
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ cd ../..
Felipe@FELIPES ~/SVN/Trunk
$ svn up
Updating '.':
U Lettus\lbin\create_appsvr_links_5.4.sh
Updated to revision 59204.
Felipe@FELIPES ~/SVN/Trunk
$ svn st
K Lettus\lbin\backup.cron
? SystemAdmin\rsync.sh
M K SystemAdmin\rsync_transfer.cron.FreshASPNEW
M K SystemAdmin\rsync_transfer.cron.FreshBNE
Felipe@FELIPES ~/SVN/Trunk
$ cd ..
Felipe@FELIPES ~/SVN
$ svn up
Updating '.':
B Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
B Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
B Trunk\Lettus\lbin\backup.cron
---end-output---
--
felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
On Thu, Aug 15, 2013 at 6:19 PM, Bert Huijben <be...@qqmail.nl> wrote:
> Hi Felipe,****
>
> Do you have access to the repository configuration at the server?****
>
> Things we are most interested in is how exactly your authentication is
> setup. E.g. do you allow anonymous acces, and if yes in what way?****
>
> Posting your server configuration (with passwords and private information
> changed) would really help.****
>
> I don’t think the serf debug log is really giving much more information
> here, as there are (as far as I can tell) no requests that fail. The
> default server side logging (if not disabled) provides most likely more
> than enough information to look into this.****
>
> Last night (EU time) we spend some time with different scenarios in an
> attempt to reproduce your issue, but we were unable to.****
>
> Bert****
>
>
Hi Bert. I do have access to the server. I posted the HTTP config here <
http://pastebin.com/ZefLnHA9>
- we do not allow anonymous access
- auth is handles by htpasswd valid-user (also use 'authz' to "hide" some
directories from some users, but I do not believe this is the case here)
I'm outputing the "access_log" of the virtualhost which runs SVN server
(apache). I hope I'm not spamming. I thought it was too small to paste on
pastebin...
ps. the 'error_log' was 0 bytes
This is output from a 1.6.15 client and 1.6.15 server. Locks are not broken
---BEGIN---
cat access_log_svntest_1.6.15
192.168.0.20 - - [15/Aug/2013:21:21:37 +1000] "OPTIONS / HTTP/1.1" 200 -
"-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:21:47 +1000] "OPTIONS / HTTP/1.1" 200 -
"-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:22:01 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:04 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 189 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:04 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:04 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:04 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND
/svn/repos/!svn/bc/4 HTTP/1.1" 207 659 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:22:06 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 189 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] "REPORT
/svn/repos/!svn/vcc/default HTTP/1.1" 200 3946 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:22:51 +1000] "OPTIONS
/svn/repos/Trunk/Lettus/lbin HTTP/1.1" 401 491 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] "OPTIONS
/svn/repos/Trunk/Lettus/lbin HTTP/1.1" 200 189 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] "PROPFIND
/svn/repos/Trunk/Lettus/lbin HTTP/1.1" 207 712 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] "PROPFIND
/svn/repos/Trunk/Lettus/lbin/file1.txt HTTP/1.1" 207 698 "-" "SVN/1.6.15
(r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] "LOCK
/svn/repos/Trunk/Lettus/lbin/file1.txt HTTP/1.1" 200 371 "-" "SVN/1.6.15
(r1038135) neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:22:55 +1000] "OPTIONS
/svn/repos/Trunk/Lettus HTTP/1.1" 401 491 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:55 +1000] "OPTIONS
/svn/repos/Trunk/Lettus HTTP/1.1" 200 189 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:55 +1000] "PROPFIND
/svn/repos/Trunk/Lettus HTTP/1.1" 207 702 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:55 +1000] "PROPFIND
/svn/repos/Trunk/Lettus HTTP/1.1" 207 702 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:55 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:55 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:22:55 +1000] "REPORT
/svn/repos/!svn/vcc/default HTTP/1.1" 200 1601 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:23:01 +1000] "OPTIONS /svn/repos/Trunk
HTTP/1.1" 401 491 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:01 +1000] "OPTIONS
/svn/repos/Trunk HTTP/1.1" 200 189 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:01 +1000] "PROPFIND
/svn/repos/Trunk HTTP/1.1" 207 688 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:01 +1000] "PROPFIND
/svn/repos/Trunk HTTP/1.1" 207 688 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:01 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:01 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:01 +1000] "REPORT
/svn/repos/!svn/vcc/default HTTP/1.1" 200 2040 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:23:08 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:08 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 189 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:08 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:08 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:08 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:08 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:08 +1000] "REPORT
/svn/repos/!svn/vcc/default HTTP/1.1" 200 2473 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:23:19 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:19 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 189 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:19 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:19 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:19 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:19 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:19 +1000] "REPORT
/svn/repos/!svn/vcc/default HTTP/1.1" 200 2473 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - - [15/Aug/2013:21:23:33 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:33 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 189 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:33 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:33 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.6.15 (r1038135) neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:33 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:33 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
192.168.0.20 - felipe [15/Aug/2013:21:23:33 +1000] "REPORT
/svn/repos/!svn/vcc/default HTTP/1.1" 200 2473 "-" "SVN/1.6.15 (r1038135)
neon/0.25.5"
---END---
And output from 1.8.1 client to 1.6.15 server (lock gets broken)
---BEGIN---
cat access_log_svntest_1.8.1
192.168.0.72 - - [15/Aug/2013:21:24:59 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - - [15/Aug/2013:21:25:14 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 189 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 97 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "PROPFIND
/svn/repos/!svn/bc/4 HTTP/1.1" 207 323 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - - [15/Aug/2013:21:25:14 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 189 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 97 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:14 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:15 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:15 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:15 +1000] "REPORT
/svn/repos/!svn/vcc/default HTTP/1.1" 200 3946 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - - [15/Aug/2013:21:25:28 +1000] "OPTIONS
/svn/repos/Trunk/Lettus/lbin HTTP/1.1" 401 491 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:28 +1000] "OPTIONS
/svn/repos/Trunk/Lettus/lbin HTTP/1.1" 200 189 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:28 +1000] "OPTIONS
/svn/repos/Trunk/Lettus/lbin HTTP/1.1" 200 97 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:28 +1000] "LOCK
/svn/repos/Trunk/Lettus/lbin/test.txt HTTP/1.1" 200 378 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - - [15/Aug/2013:21:25:43 +1000] "OPTIONS /svn/repos HTTP/1.1"
401 491 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:43 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 189 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:43 +1000] "OPTIONS /svn/repos
HTTP/1.1" 200 97 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:43 +1000] "PROPFIND /svn/repos
HTTP/1.1" 207 649 "-" "SVN/1.8.1 (x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:43 +1000] "PROPFIND
/svn/repos/!svn/vcc/default HTTP/1.1" 207 400 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:43 +1000] "PROPFIND
/svn/repos/!svn/bln/4 HTTP/1.1" 207 451 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
192.168.0.72 - felipe [15/Aug/2013:21:25:43 +1000] "REPORT
/svn/repos/!svn/vcc/default HTTP/1.1" 200 2471 "-" "SVN/1.8.1
(x64-microsoft-windows) serf/1.3.0"
---END---
I'm using svn.exe from TSVN inside cygwin env.
--
Felipe
RE: svn 1.8 causing locks to be broken on update
Posted by Bert Huijben <be...@qqmail.nl>.
Hi Felipe,
Do you have access to the repository configuration at the server?
Things we are most interested in is how exactly your authentication is setup. E.g. do you allow anonymous acces, and if yes in what way?
Posting your server configuration (with passwords and private information changed) would really help.
I don’t think the serf debug log is really giving much more information here, as there are (as far as I can tell) no requests that fail. The default server side logging (if not disabled) provides most likely more than enough information to look into this.
Last night (EU time) we spend some time with different scenarios in an attempt to reproduce your issue, but we were unable to.
Bert
From: Felipe Alvarez [mailto:felipe.alvarez@gmail.com]
Sent: donderdag 15 augustus 2013 04:29
To: Johan Corveleyn; William Smith; philip.martin@wandisco.com
Cc: Hiroharu Tamaru; Users Subversion Apache
Subject: Re: svn 1.8 causing locks to be broken on update
As of 1.8 SVN only uses the serf library for http communication, and
no longer the neon library (before 1.8, both were part of svn, but
neon was the default library).
Unfortunately there is no runtime-switch (yet) to enable debug output
with svn+serf. There is already an open enhancement request for this
[1].
You can enable debug logging with serf by rebuilding (see [2]).
With your combined input, this issue really starts to look like a
serf-related issue.
- Succeeds with file:// <file:///\\>
- Fails with http(s), but only with 1.8 clients, not with older clients.
To double check that it's serf-related, perhaps one of you could try
with 1.7+serf, and see if that fails as well. You can enable serf with
1.7 by specifying http-library=serf in the servers configuration file,
or by passing
--config-option servers:global:http-library=serf
on the command line.
Perhaps it's time to open an issue in the issue tracker for this.
Subversion client 1.7 using serf cause the lock to break! But it does not break when using neon (default)
---8<-------
C:\tmp>svn --username will --password will co http://svntest.freshcomp.com.au/svn/repos --config-option servers:global:http-library=serf wc
A wc\Trunk
A wc\Trunk\Lettus
A wc\Trunk\Lettus\lbin
A wc\Trunk\Lettus\lbin\file2.txt
A wc\Trunk\Lettus\lbin\test.txt
A wc\Trunk\Lettus\lbin\file1.txt
Checked out revision 4.
C:\tmp>cd wc\Trunk\Lettus\lbin
C:\tmp\wc\Trunk\Lettus\lbin>dir
Directory of C:\tmp\wc\Trunk\Lettus\lbin
15/08/2013 12:07 PM <DIR> .
15/08/2013 12:07 PM <DIR> ..
13/08/2013 01:14 PM 6 file1.txt
13/08/2013 05:01 PM 5 file2.txt
13/08/2013 05:35 PM 6 test.txt
3 File(s) 17 bytes
2 Dir(s) 89,690,247,168 bytes free
C:\tmp\wc\Trunk\Lettus\lbin>svn lock test.txt --config-option servers:global:http-library=serf
'test.txt' locked by user 'will'.
C:\tmp\wc\Trunk\Lettus\lbin>svn st --config-option servers:global:http-library=serf
K test.txt
C:\tmp\wc\Trunk\Lettus\lbin>cd ..
C:\tmp\wc\Trunk\Lettus>svn up --config-option servers:global:http-library=serf
Updating '.':
At revision 4.
C:\tmp\wc\Trunk\Lettus>cd ..
C:\tmp\wc\Trunk>svn up --config-option servers:global:http-library=serf
Updating '.':
At revision 4.
C:\tmp\wc\Trunk>cd ..
C:\tmp\wc>svn up --config-option servers:global:http-library=serf
Updating '.':
UB Trunk\Lettus\lbin\test.txt
Updated to revision 4.
C:\tmp\wc>svn st --config-option servers:global:http-library=serf
C:\tmp\wc>
---8<-------
--
Felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
As of 1.8 SVN only uses the serf library for http communication, and
> no longer the neon library (before 1.8, both were part of svn, but
> neon was the default library).
>
> Unfortunately there is no runtime-switch (yet) to enable debug output
> with svn+serf. There is already an open enhancement request for this
> [1].
>
> You can enable debug logging with serf by rebuilding (see [2]).
>
> With your combined input, this issue really starts to look like a
> serf-related issue.
> - Succeeds with file://
> - Fails with http(s), but only with 1.8 clients, not with older clients.
>
> To double check that it's serf-related, perhaps one of you could try
> with 1.7+serf, and see if that fails as well. You can enable serf with
> 1.7 by specifying http-library=serf in the servers configuration file,
> or by passing
> --config-option servers:global:http-library=serf
> on the command line.
>
> Perhaps it's time to open an issue in the issue tracker for this.
>
>
Subversion client 1.7 using serf cause the lock to break! But it does not
break when using neon (default)
---8<-------
C:\tmp>svn --username will --password will co
http://svntest.freshcomp.com.au/svn/repos --config-option
servers:global:http-library=serf wc
A wc\Trunk
A wc\Trunk\Lettus
A wc\Trunk\Lettus\lbin
A wc\Trunk\Lettus\lbin\file2.txt
A wc\Trunk\Lettus\lbin\test.txt
A wc\Trunk\Lettus\lbin\file1.txt
Checked out revision 4.
C:\tmp>cd wc\Trunk\Lettus\lbin
C:\tmp\wc\Trunk\Lettus\lbin>dir
Directory of C:\tmp\wc\Trunk\Lettus\lbin
15/08/2013 12:07 PM <DIR> .
15/08/2013 12:07 PM <DIR> ..
13/08/2013 01:14 PM 6 file1.txt
13/08/2013 05:01 PM 5 file2.txt
13/08/2013 05:35 PM 6 test.txt
3 File(s) 17 bytes
2 Dir(s) 89,690,247,168 bytes free
C:\tmp\wc\Trunk\Lettus\lbin>svn lock test.txt --config-option
servers:global:http-library=serf
'test.txt' locked by user 'will'.
C:\tmp\wc\Trunk\Lettus\lbin>svn st --config-option
servers:global:http-library=serf
K test.txt
C:\tmp\wc\Trunk\Lettus\lbin>cd ..
C:\tmp\wc\Trunk\Lettus>svn up --config-option
servers:global:http-library=serf
Updating '.':
At revision 4.
C:\tmp\wc\Trunk\Lettus>cd ..
C:\tmp\wc\Trunk>svn up --config-option servers:global:http-library=serf
Updating '.':
At revision 4.
C:\tmp\wc\Trunk>cd ..
C:\tmp\wc>svn up --config-option servers:global:http-library=serf
Updating '.':
UB Trunk\Lettus\lbin\test.txt
Updated to revision 4.
C:\tmp\wc>svn st --config-option servers:global:http-library=serf
C:\tmp\wc>
---8<-------
--
Felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Aug 15, 2013 at 10:30 AM, Lieven Govaerts
<li...@gmail.com> wrote:
> On Wed, Aug 14, 2013 at 11:30 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez
>> <fe...@gmail.com> wrote:
...
>>> How do I enabled debugging in .subversion/config or .subversion/servers? It
>>> used to be something like "neon-debug" but that's no longer available since
>>> 1.8.1 (or 1.8)
>>>
>>
>> As of 1.8 SVN only uses the serf library for http communication, and
>> no longer the neon library (before 1.8, both were part of svn, but
>> neon was the default library).
>>
>> Unfortunately there is no runtime-switch (yet) to enable debug output
>> with svn+serf. There is already an open enhancement request for this
>> [1].
>>
>> You can enable debug logging with serf by rebuilding (see [2]).
>
> A FYI to Johan: note that there are two levels of abstraction here:
> - serf: the http library that's now used instead of neon: implements
> the http protocol and sends/receives bytes over the network
> - ra_serf: the subversion ra module that uses serf to communicate with
> a mod_dav_svn module in an apache server via XML request/reply
> messaging
>
> If there's an issue that looks like missing or corrupted data,
> connection or authentication problems then we look to the serf
> library. The logging you refer to is then a good way to start
> gathering info on what's going wrong.
>
> However in this case it seems that the communication itself is ok, but
> there's a potential issue in how ra_serf drives the communication
> (i.e. the content of the xml requests). Serf logging will not help
> here as it's a level too deep. A simple wireshark trace can help, once
> the exact reproduction recipe is known.
> (serf can also log request and reply output, even with https, but it's
> easier to use wireshark)
>
> Lieven
Ah yes, thanks. I will keep that in mind.
--
Johan
Re: svn 1.8 causing locks to be broken on update
Posted by Lieven Govaerts <li...@gmail.com>.
On Wed, Aug 14, 2013 at 11:30 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez
> <fe...@gmail.com> wrote:
>>>
>>> I have the same issue.
>>>
>>> It happens when I run 1.8.1 windows client with 1.6.9 https
>>> repository sever. I haven't tried so many combinations ATM,
>>> but here are some observations:
>>>
>>> 1.8.1 client run with 1.6.9 https:// repo server gives this issue.
>>> 1.8.1 client run with 1.6.9 generated file:/// repositories are OK.
>>> 1.8.1 client run with 1.7.6 generated file:/// repositories are OK.
>>> 1.7.6 client run with 1.6.9 https:// repo server is OK.
>>>
>>> Whether the WC is freshly checked out by 1.8.1 client, or upgraded
>>> from 1.7.6 checked out WC did not change the results.
>>>
>>> How's the case for the original poster? Do we see something
>>> in common?
>>>
>>> # I'm reading this ML through the archives.
>>> --
>>> Hiroharu
>>
>>
>> Hi Hiroharu
>>
>> You are indeed correct. We have done a very similar experiment here, too. We
>> tried all of the above scenarios you gave. But our older client was 1.6.15,
>> and we did not use https, we used http (apache 2.2)
>>
>> With the help of my colleague we have done some testing with svn 1.8.1
>> (windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client.
>>
>> Using the file:/// method in all cases works fine (locks NOT broken). All
>> other methods also work fine, including http. Of the tests we made, the one
>> which breaks the locks is: client 1.8.1; repository made with svn 1.6.15;
>> protocol HTTP (apache 2.2).
>>
>> One method that we have not yet tried is: client 1.8.1; repo with svn client
>> 1.8.1; protocol HTTP
>>
>> How do I enabled debugging in .subversion/config or .subversion/servers? It
>> used to be something like "neon-debug" but that's no longer available since
>> 1.8.1 (or 1.8)
>>
>
> As of 1.8 SVN only uses the serf library for http communication, and
> no longer the neon library (before 1.8, both were part of svn, but
> neon was the default library).
>
> Unfortunately there is no runtime-switch (yet) to enable debug output
> with svn+serf. There is already an open enhancement request for this
> [1].
>
> You can enable debug logging with serf by rebuilding (see [2]).
A FYI to Johan: note that there are two levels of abstraction here:
- serf: the http library that's now used instead of neon: implements
the http protocol and sends/receives bytes over the network
- ra_serf: the subversion ra module that uses serf to communicate with
a mod_dav_svn module in an apache server via XML request/reply
messaging
If there's an issue that looks like missing or corrupted data,
connection or authentication problems then we look to the serf
library. The logging you refer to is then a good way to start
gathering info on what's going wrong.
However in this case it seems that the communication itself is ok, but
there's a potential issue in how ra_serf drives the communication
(i.e. the content of the xml requests). Serf logging will not help
here as it's a level too deep. A simple wireshark trace can help, once
the exact reproduction recipe is known.
(serf can also log request and reply output, even with https, but it's
easier to use wireshark)
Lieven
> With your combined input, this issue really starts to look like a
> serf-related issue.
> - Succeeds with file://
> - Fails with http(s), but only with 1.8 clients, not with older clients.
>
> To double check that it's serf-related, perhaps one of you could try
> with 1.7+serf, and see if that fails as well. You can enable serf with
> 1.7 by specifying http-library=serf in the servers configuration file,
> or by passing
> --config-option servers:global:http-library=serf
> on the command line.
>
> Perhaps it's time to open an issue in the issue tracker for this.
>
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4407 (Provide
> serf equivalent of neon-debug-mask)
>
> [2] http://svn.haxx.se/users/archive-2013-07/0344.shtml
>
> --
> Johan
Re: svn 1.8 causing locks to be broken on update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez
<fe...@gmail.com> wrote:
>>
>> I have the same issue.
>>
>> It happens when I run 1.8.1 windows client with 1.6.9 https
>> repository sever. I haven't tried so many combinations ATM,
>> but here are some observations:
>>
>> 1.8.1 client run with 1.6.9 https:// repo server gives this issue.
>> 1.8.1 client run with 1.6.9 generated file:/// repositories are OK.
>> 1.8.1 client run with 1.7.6 generated file:/// repositories are OK.
>> 1.7.6 client run with 1.6.9 https:// repo server is OK.
>>
>> Whether the WC is freshly checked out by 1.8.1 client, or upgraded
>> from 1.7.6 checked out WC did not change the results.
>>
>> How's the case for the original poster? Do we see something
>> in common?
>>
>> # I'm reading this ML through the archives.
>> --
>> Hiroharu
>
>
> Hi Hiroharu
>
> You are indeed correct. We have done a very similar experiment here, too. We
> tried all of the above scenarios you gave. But our older client was 1.6.15,
> and we did not use https, we used http (apache 2.2)
>
> With the help of my colleague we have done some testing with svn 1.8.1
> (windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client.
>
> Using the file:/// method in all cases works fine (locks NOT broken). All
> other methods also work fine, including http. Of the tests we made, the one
> which breaks the locks is: client 1.8.1; repository made with svn 1.6.15;
> protocol HTTP (apache 2.2).
>
> One method that we have not yet tried is: client 1.8.1; repo with svn client
> 1.8.1; protocol HTTP
>
> How do I enabled debugging in .subversion/config or .subversion/servers? It
> used to be something like "neon-debug" but that's no longer available since
> 1.8.1 (or 1.8)
>
As of 1.8 SVN only uses the serf library for http communication, and
no longer the neon library (before 1.8, both were part of svn, but
neon was the default library).
Unfortunately there is no runtime-switch (yet) to enable debug output
with svn+serf. There is already an open enhancement request for this
[1].
You can enable debug logging with serf by rebuilding (see [2]).
With your combined input, this issue really starts to look like a
serf-related issue.
- Succeeds with file://
- Fails with http(s), but only with 1.8 clients, not with older clients.
To double check that it's serf-related, perhaps one of you could try
with 1.7+serf, and see if that fails as well. You can enable serf with
1.7 by specifying http-library=serf in the servers configuration file,
or by passing
--config-option servers:global:http-library=serf
on the command line.
Perhaps it's time to open an issue in the issue tracker for this.
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=4407 (Provide
serf equivalent of neon-debug-mask)
[2] http://svn.haxx.se/users/archive-2013-07/0344.shtml
--
Johan
Re: svn 1.8 causing locks to be broken on update
Posted by Branko Čibej <br...@wandisco.com>.
On 08.09.2013 11:03, Felipe Alvarez wrote:
> You could try one of these (i386 versions are also available):
>
>
> http://opensource.wandisco.com/centos/5/RPMS/x86_64/
>
> They're made fore CentOS, but AIUI, should work on RHEL as well.
> 1.6.17 isn't there, but newer versions are; I'd suggest trying the
> latest, 1.6.23-2.
>
>
> Are these "Apache standard SVN" editions? Or have they been enhanced
> by WANDisco?
As far as I'm aware, these are built from unchanged Subversion release
tarballs.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
You could try one of these (i386 versions are also available):
>
> http://opensource.wandisco.com/centos/5/RPMS/x86_64/
>
> They're made fore CentOS, but AIUI, should work on RHEL as well. 1.6.17
> isn't there, but newer versions are; I'd suggest trying the latest,
> 1.6.23-2.
>
Are these "Apache standard SVN" editions? Or have they been enhanced by
WANDisco?
--
Felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Branko Čibej <br...@wandisco.com>.
On 06.09.2013 03:20, Felipe Alvarez wrote:
> Thanks for your reply. I didn't mean to rush things, only to ask on
> the status. We can wait for the bug to be fixed, as our OS is possibly
> too old to run 1.6.17 (RHEL 5.5) and repoforge contains RPM for
> RHEL5.5 up to 1.6.15 only.
You could try one of these (i386 versions are also available):
http://opensource.wandisco.com/centos/5/RPMS/x86_64/
They're made fore CentOS, but AIUI, should work on RHEL as well. 1.6.17
isn't there, but newer versions are; I'd suggest trying the latest,
1.6.23-2.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
Thanks for your reply. I didn't mean to rush things, only to ask on the
status. We can wait for the bug to be fixed, as our OS is possibly too old
to run 1.6.17 (RHEL 5.5) and repoforge contains RPM for RHEL5.5 up to
1.6.15 only.
Cheers,
Felipe
On Fri, Sep 6, 2013 at 10:23 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 06.09.2013 02:06, Felipe Alvarez wrote:
> > I have upgraded my tortoiseSVN to 1.8.2 which includes svn version
> > 1.8.3 (r1516576). The problem is still there (locks broken on update).
> >
> > I have not seen any progress on the bug report
> > <http://subversion.tigris.org/issues/show_bug.cgi?id=4412>
>
> It's been less than a month since you reported it, and a bit more than
> two weeks since the cause was determined. Do please remember that this
> is a volunteer project. There's no need to keep nagging.
>
> In the meantime, have you implemented the workaround that Philip
> mentioned, i.e., upgrading your server to version 1.6.17?
>
> Thanks,
>
> -- Brane
>
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane@wandisco.com
>
Re: svn 1.8 causing locks to be broken on update
Posted by Branko Čibej <br...@wandisco.com>.
On 06.09.2013 02:06, Felipe Alvarez wrote:
> I have upgraded my tortoiseSVN to 1.8.2 which includes svn version
> 1.8.3 (r1516576). The problem is still there (locks broken on update).
>
> I have not seen any progress on the bug report
> <http://subversion.tigris.org/issues/show_bug.cgi?id=4412>
It's been less than a month since you reported it, and a bit more than
two weeks since the cause was determined. Do please remember that this
is a volunteer project. There's no need to keep nagging.
In the meantime, have you implemented the workaround that Philip
mentioned, i.e., upgrading your server to version 1.6.17?
Thanks,
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
I have upgraded my tortoiseSVN to 1.8.2 which includes svn version 1.8.3
(r1516576). The problem is still there (locks broken on update).
I have not seen any progress on the bug report <
http://subversion.tigris.org/issues/show_bug.cgi?id=4412>
Cheers,
Felipe
On Fri, Aug 23, 2013 at 11:21 AM, Felipe Alvarez
<fe...@gmail.com>wrote:
>
>
>
> Johan Corveleyn <jc...@gmail.com> writes:
>>
>> > 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?
>>
>> It appears to be related to a path handling bug in code that is supposed
>> to handle old servers, the obvious fix makes the problem worse. I've
>> raised http://subversion.tigris.org/issues/show_bug.cgi?id=4412
>>
>> --
>> Philip Martin | Subversion Committer
>> WANdisco // *Non-Stop Data*
>>
>
> Hi Philip
>
> How is this bug fix progressing?
>
>
> Cheers,
> Felipe
>
>
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
Johan Corveleyn <jc...@gmail.com> writes:
>
> > 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?
>
> It appears to be related to a path handling bug in code that is supposed
> to handle old servers, the obvious fix makes the problem worse. I've
> raised http://subversion.tigris.org/issues/show_bug.cgi?id=4412
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
>
Hi Philip
How is this bug fix progressing?
Cheers,
Felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> 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?
It appears to be related to a path handling bug in code that is supposed
to handle old servers, the obvious fix makes the problem worse. I've
raised http://subversion.tigris.org/issues/show_bug.cgi?id=4412
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn 1.8 causing locks to be broken on update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Aug 15, 2013 at 12:12 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Philip Martin [mailto:philip.martin@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 <fe...@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
RE: svn 1.8 causing locks to be broken on update
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@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 <fe...@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
Re: svn 1.8 causing locks to be broken on update
Posted by Philip Martin <ph...@wandisco.com>.
Felipe Alvarez <fe...@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.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
> Can you provide a complete recipe?
>
> 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?
Could you make a repo on a remote server, with a real svn 1.6.xx, and 1.8
or 1.8.1 client?
-- Felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Philip Martin <ph...@wandisco.com>.
Felipe Alvarez <fe...@gmail.com> writes:
>>
>>
>> I have the same issue.
>>
>> It happens when I run 1.8.1 windows client with 1.6.9 https
>> repository sever. I haven't tried so many combinations ATM,
>> but here are some observations:
>>
>
> Hi Hiroharu
>
> You are indeed correct. We have done a very similar experiment here, too.
> We tried all of the above scenarios you gave. But our older client was
> 1.6.15, and we did not use https, we used http (apache 2.2)
>
> With the help of my colleague we have done some testing with svn 1.8.1
> (windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client.
Can you provide a complete recipe?
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*
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
>
>
> I have the same issue.
>
> It happens when I run 1.8.1 windows client with 1.6.9 https
> repository sever. I haven't tried so many combinations ATM,
> but here are some observations:
>
> 1.8.1 client run with 1.6.9 https:// repo server gives this issue.
> 1.8.1 client run with 1.6.9 generated file:/// repositories are OK.
> 1.8.1 client run with 1.7.6 generated file:/// repositories are OK.
> 1.7.6 client run with 1.6.9 https:// repo server is OK.
>
> Whether the WC is freshly checked out by 1.8.1 client, or upgraded
> from 1.7.6 checked out WC did not change the results.
>
> How's the case for the original poster? Do we see something
> in common?
>
> # I'm reading this ML through the archives.
> --
> Hiroharu
>
Hi Hiroharu
You are indeed correct. We have done a very similar experiment here, too.
We tried all of the above scenarios you gave. But our older client was
1.6.15, and we did not use https, we used http (apache 2.2)
With the help of my colleague we have done some testing with svn 1.8.1
(windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client.
Using the file:/// method in all cases works fine (locks NOT broken). All
other methods also work fine, including http. Of the tests we made, the one
which breaks the locks is: client 1.8.1; repository made with svn 1.6.15;
protocol HTTP (apache 2.2).
One method that we have not yet tried is: client 1.8.1; repo with svn
client 1.8.1; protocol HTTP
How do I enabled debugging in .subversion/config or .subversion/servers? It
used to be something like "neon-debug" but that's no longer available since
1.8.1 (or 1.8)
-- felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Aug 12, 2013 at 5:38 AM, Felipe Alvarez
<fe...@gmail.com> wrote:
>
> On Mon, Aug 5, 2013 at 9:50 AM, Felipe Alvarez <fe...@gmail.com>
> wrote:
>>
>> Maybe I'm missing something but what exactly is broken in your
>>>
>>> output? It ends with svn up, but shouldn't be there at least one
>>> additional svn st to show something about the lock?
>>>
>>> > Felipe@FELIPES ~/SVN
>>> > $ svn up
>>> > Updating '.':
>>> > B Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
>>> > B Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
>>> > B Trunk\Lettus\lbin\backup.cron
>>>
>>> svn up doesn't show info about your locked file because it didn't
>>> change or conflict with revisions from the repo.
>>>
>> My apologies. I have tried it again, this time with final 'svn st'
>>
>> ---begin output---
>>
>> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
>> $ svn st
>>
>> #---------------------------------------------
>> # lock broken from previous update (last week)
>> #---------------------------------------------
>>
>> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
>> $ svn lock backup.cron
>> svn: warning: W160035: Path '/Trunk/Lettus/lbin/backup.cron' is already
>> locked by user 'felipe' in filesystem '/u3/SVN_Repository/db'
>>
>> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
>> $ svn lock --force backup.cron
>> 'backup.cron' locked by user 'felipe'.
>>
>> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
>> $ svn st
>> K backup.cron
>>
>> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
>> $ cd ..
>>
>> Felipe@FELIPES ~/SVN/Trunk/Lettus
>> $ svn up; svn st
>> Updating '.':
>> At revision 59397.
>> K lbin\backup.cron
>>
>> Felipe@FELIPES ~/SVN/Trunk/Lettus
>> $ cd ..
>>
>> Felipe@FELIPES ~/SVN/Trunk
>> $ svn up; svn st
>> Updating '.':
>> At revision 59397.
>>
>> K Lettus\lbin\backup.cron
>> ? SystemAdmin\rsync.sh
>> M SystemAdmin\rsync_transfer.cron.FreshASPNEW
>>
>> M SystemAdmin\rsync_transfer.cron.FreshBNE
>>
>> Felipe@FELIPES ~/SVN/Trunk
>> $ cd ..
>>
>> Felipe@FELIPES ~/SVN
>> $ svn st
>> MM Branches\Lettus\UAT\prod\autotest\code_check.sh
>> K Trunk\Lettus\lbin\backup.cron
>> ? Trunk\SystemAdmin\rsync.sh
>> M Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
>> M Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
>> ? wclbin
>>
>>
>> Felipe@FELIPES ~/SVN
>> $ svn up
>> Updating '.':
>> B Trunk\Lettus\lbin\backup.cron
>> At revision 59397.
>>
>> Felipe@FELIPES ~/SVN
>> $ svn st
>> MM Branches\Lettus\UAT\prod\autotest\code_check.sh
>> ? Trunk\SystemAdmin\rsync.sh
>> M Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
>> M Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
>> ? wclbin
>>
>> Felipe@FELIPES ~/SVN
>> $
>>
>> ---end output---
>>
>> --
>> Felipe
>>
>
> Has anybody been able to reproduce or confirm this problem?
>
I've tried, but I can't reproduce this problem with a clean repository
(see transcript below).
There must be something special with your repository or working copy.
Maybe your working copy is constructed in a special way, for instance
a sparse working copy, or with switched subtrees or something like
that? Or perhaps your ~/SVN/Trunk is, through the use of symlinks,
part of two different working copies?
I think you'll have to narrow this down to something reproducible, or
give additional details about your repository and working copy, before
anyone will be able to help. I suggest you first examine your current
working copy to see if there is anything special about it (with 'svn
info' etc). And then try to reproduce it in a completely new working
copy (make a new checkout of the same part of the repository, and
trying the same steps). If you can reproduce it that way, that's
already a good step forward. Next thing is to reproduce it from
scratch with a completely new repository (like I tried in the
transcript below).
Here's what I tried (with svn built from trunk@1513012):
[[[
C:\Temp\test>svnadmin create repos
C:\Temp\test>svn co file:///c:/temp/test/repos wc
Checked out revision 0.
C:\Temp\test>cd wc
C:\Temp\test\wc>svn mkdir --parents -m"creating dirs"
file:///c:/temp/test/repos/Trunk/Lettus/lbin
Committed revision 1.
C:\Temp\test\wc>svn up
Updating '.':
A Trunk
A Trunk\Lettus
A Trunk\Lettus\lbin
Updated to revision 1.
C:\Temp\test\wc>cd Trunk\Lettus\lbin
C:\Temp\test\wc\Trunk\Lettus\lbin>echo line1 > test.txt
C:\Temp\test\wc\Trunk\Lettus\lbin>svn add test.txt
A test.txt
C:\Temp\test\wc\Trunk\Lettus\lbin>svn ci -m"adding test file"
Adding test.txt
Transmitting file data .
Committed revision 2.
C:\Temp\test\wc\Trunk\Lettus\lbin>svn lock --username jcorvel test.txt
'test.txt' locked by user 'jcorvel'.
C:\Temp\test\wc\Trunk\Lettus\lbin>svn st
K test.txt
C:\Temp\test\wc\Trunk\Lettus\lbin>cd ..
C:\Temp\test\wc\Trunk\Lettus>svn st
K lbin\test.txt
C:\Temp\test\wc\Trunk\Lettus>cd ..
C:\Temp\test\wc\Trunk>svn up
Updating '.':
At revision 2.
C:\Temp\test\wc\Trunk>svn st
K Lettus\lbin\test.txt
C:\Temp\test\wc\Trunk>cd ..
C:\Temp\test\wc>svn st
K Trunk\Lettus\lbin\test.txt
C:\Temp\test\wc>svn up
Updating '.':
At revision 2.
C:\Temp\test\wc>svn st
K Trunk\Lettus\lbin\test.txt
]]]
--
Johan
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
On Mon, Aug 5, 2013 at 9:50 AM, Felipe Alvarez <fe...@gmail.com>wrote:
> Maybe I'm missing something but what exactly is broken in your
>
>> output? It ends with svn up, but shouldn't be there at least one
>> additional svn st to show something about the lock?
>>
>> > Felipe@FELIPES ~/SVN
>> > $ svn up
>> > Updating '.':
>> > B Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
>> > B Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
>> > B Trunk\Lettus\lbin\backup.cron
>>
>> svn up doesn't show info about your locked file because it didn't
>> change or conflict with revisions from the repo.
>>
>> My apologies. I have tried it again, this time with final 'svn st'
>
> ---begin output---
>
> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
> $ svn st
>
> #---------------------------------------------
> # lock broken from previous update (last week)
> #---------------------------------------------
>
> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
> $ svn lock backup.cron
> svn: warning: W160035: Path '/Trunk/Lettus/lbin/backup.cron' is already
> locked by user 'felipe' in filesystem '/u3/SVN_Repository/db'
>
> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
> $ svn lock --force backup.cron
> 'backup.cron' locked by user 'felipe'.
>
> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
> $ svn st
> K backup.cron
>
> Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
> $ cd ..
>
> Felipe@FELIPES ~/SVN/Trunk/Lettus
> $ svn up; svn st
> Updating '.':
> At revision 59397.
> K lbin\backup.cron
>
> Felipe@FELIPES ~/SVN/Trunk/Lettus
> $ cd ..
>
> Felipe@FELIPES ~/SVN/Trunk
> $ svn up; svn st
> Updating '.':
> At revision 59397.
>
> K Lettus\lbin\backup.cron
> ? SystemAdmin\rsync.sh
> M SystemAdmin\rsync_transfer.cron.FreshASPNEW
>
> M SystemAdmin\rsync_transfer.cron.FreshBNE
>
> Felipe@FELIPES ~/SVN/Trunk
> $ cd ..
>
> Felipe@FELIPES ~/SVN
> $ svn st
> MM Branches\Lettus\UAT\prod\autotest\code_check.sh
> K Trunk\Lettus\lbin\backup.cron
> ? Trunk\SystemAdmin\rsync.sh
> M Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
> M Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
> ? wclbin
>
>
> Felipe@FELIPES ~/SVN
> $ svn up
> Updating '.':
> B Trunk\Lettus\lbin\backup.cron
> At revision 59397.
>
> Felipe@FELIPES ~/SVN
> $ svn st
> MM Branches\Lettus\UAT\prod\autotest\code_check.sh
> ? Trunk\SystemAdmin\rsync.sh
> M Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
> M Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
> ? wclbin
>
> Felipe@FELIPES ~/SVN
> $
>
> ---end output---
>
> --
> Felipe
>
>
Has anybody been able to reproduce or confirm this problem?
Thanks
--
Felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Felipe Alvarez <fe...@gmail.com>.
Maybe I'm missing something but what exactly is broken in your
> output? It ends with svn up, but shouldn't be there at least one
> additional svn st to show something about the lock?
>
> > Felipe@FELIPES ~/SVN
> > $ svn up
> > Updating '.':
> > B Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
> > B Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
> > B Trunk\Lettus\lbin\backup.cron
>
> svn up doesn't show info about your locked file because it didn't
> change or conflict with revisions from the repo.
>
> My apologies. I have tried it again, this time with final 'svn st'
---begin output---
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ svn st
#---------------------------------------------
# lock broken from previous update (last week)
#---------------------------------------------
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ svn lock backup.cron
svn: warning: W160035: Path '/Trunk/Lettus/lbin/backup.cron' is already
locked by user 'felipe' in filesystem '/u3/SVN_Repository/db'
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ svn lock --force backup.cron
'backup.cron' locked by user 'felipe'.
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ svn st
K backup.cron
Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin
$ cd ..
Felipe@FELIPES ~/SVN/Trunk/Lettus
$ svn up; svn st
Updating '.':
At revision 59397.
K lbin\backup.cron
Felipe@FELIPES ~/SVN/Trunk/Lettus
$ cd ..
Felipe@FELIPES ~/SVN/Trunk
$ svn up; svn st
Updating '.':
At revision 59397.
K Lettus\lbin\backup.cron
? SystemAdmin\rsync.sh
M SystemAdmin\rsync_transfer.cron.FreshASPNEW
M SystemAdmin\rsync_transfer.cron.FreshBNE
Felipe@FELIPES ~/SVN/Trunk
$ cd ..
Felipe@FELIPES ~/SVN
$ svn st
MM Branches\Lettus\UAT\prod\autotest\code_check.sh
K Trunk\Lettus\lbin\backup.cron
? Trunk\SystemAdmin\rsync.sh
M Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
M Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
? wclbin
Felipe@FELIPES ~/SVN
$ svn up
Updating '.':
B Trunk\Lettus\lbin\backup.cron
At revision 59397.
Felipe@FELIPES ~/SVN
$ svn st
MM Branches\Lettus\UAT\prod\autotest\code_check.sh
? Trunk\SystemAdmin\rsync.sh
M Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
M Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
? wclbin
Felipe@FELIPES ~/SVN
$
---end output---
--
Felipe
Re: svn 1.8 causing locks to be broken on update
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Felipe Alvarez,
am Sonntag, 4. August 2013 um 06:41 schrieben Sie:
> 'm using tortoiseSVN, and noticed that when updating the very root
> of the repository, locks which I have taken under it become broken. Here is output from cygwin.
Maybe I'm missing something but what exactly is broken in your
output? It ends with svn up, but shouldn't be there at least one
additional svn st to show something about the lock?
> Felipe@FELIPES ~/SVN
> $ svn up
> Updating '.':
> B Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW
> B Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE
> B Trunk\Lettus\lbin\backup.cron
svn up doesn't show info about your locked file because it didn't
change or conflict with revisions from the repo.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow