On Sat, Oct 28, 2017 at 2:16 PM, Johan Corveleyn <jcor...@gmail.com> wrote:
> On Fri, Oct 27, 2017 at 9:36 PM, Dan Ellis <danelli...@gmail.com> wrote: > > On Fri, Oct 27, 2017 at 12:06 AM, Johan Corveleyn <jcor...@gmail.com> > wrote: > >> > >> On Thu, Oct 26, 2017 at 11:50 PM, Dan Ellis <danelli...@gmail.com> > wrote: > >> > > >> > Hi, > >> > > >> > I brought this up back in 2014 > >> > (https://svn.haxx.se/users/archive-2014-05/0115.shtml). I managed > to work > >> > around it but just ended up running into it again. I'm running SVN > 1.8.13. > >> > > >> > C:\Project_files\wc1>svn rename C:\project_files\wc1\foo.c bar.c > >> > svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help > cleanup' > >> > for details) > >> > svn: E155004: Working copy 'C:\Project_files\wc1' locked. > >> > svn: E155004: 'C:\Project_files\wc1' is already locked. > >> > > >> > > >> > C:\Project_files\wc1>svn rename foo.c bar.c > >> > A bar.c > >> > D foo.c > >> > > >> > Can anyone else confirm this is an issue before I cross it over to > dev? > >> > >> Hi Dan, > >> > >> I've tried this with a 1.9.1 svn client, and it seems to work fine. So > >> I guess this was fixed in 1.9. > >> > >> -- > >> Johan > > > > OK, so I installed 1.9.7 just now and I still get the same issue.... > > but.... > > > > It looks like it might be related to if the working copy is based on a > > file:/// repo. If I do a rename with an absolute path for SRC for a > working > > copy not based on a file:///, it does work. > > > > Would you mind trying a new local repo? > > > > Thanks! > > (Dan, just a small thing: please don't top-post on this list, but put > your reply at the bottom or inline, thanks) > > I thought I had tried this before, and couldn't reproduce it. But now > I tried again, and ... lo and behold: > > [[[ > 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>echo test > foo.txt > > C:\Temp\test\wc>svn add foo.txt > A foo.txt > > C:\Temp\test\wc>svn ci -mm > Adding foo.txt > Transmitting file data .done > Committing transaction... > Committed revision 1. > > C:\Temp\test\wc>svn rename C:\temp\test\wc\foo.txt bar.txt > svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help > cleanup' for details) > svn: E155004: Working copy 'C:\Temp\test\wc' locked. > svn: E155004: 'C:\Temp\test\wc' is already locked. > > C:\Temp\test\wc>svn rename C:\Temp\test\wc\foo.txt bar.txt > A bar.txt > D foo.txt > ]]] > > Can you spot the difference between the first (failed) attempt for the > rename, and the second (successful) one? > > Right, if I specify a different "casing" for the SRC absolute path > ("temp" instead of "Temp"), it fails like you said. If I use the exact > casing from the on-disk path, it succeeds. That's interesting :-), and > clearly a bug. > > I've tried again with a trunk (1.10 under development) from a couple > of weeks ago, and it still fails: > > [[[ > C:\Temp\test\wc>C:\research\svn\dev\trunk\dist\bin\svn rename > C:\temp\test\wc\foo.txt bar.txt > ..\..\..\subversion\svn\svn.c:3149: (apr_err=SVN_ERR_WC_LOCKED) > svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help > cleanup' for details) > ..\..\..\subversion\svn\move-cmd.c:102, > ..\..\..\subversion\svn\util.c:555, > ..\..\..\subversion\libsvn_client\copy.c:3298, > ..\..\..\subversion\libsvn_client\copy.c:3082, > ..\..\..\subversion\libsvn_client\copy.c:925, > ..\..\..\subversion\libsvn_client\copy.c:834, > ..\..\..\subversion\libsvn_wc\lock.c:1560, > ..\..\..\subversion\libsvn_wc\wc_db.c:14588, > ..\..\..\subversion\libsvn_wc\wc_db.c:14503: (apr_err=SVN_ERR_WC_LOCKED) > svn: E155004: Working copy 'C:\Temp\test\wc' locked. > ..\..\..\subversion\libsvn_wc\wc_db.c:14495: (apr_err=SVN_ERR_WC_LOCKED) > svn: E155004: 'C:\Temp\test\wc' is already locked. > ]]] > > So, thanks for finding and reporting this :-). I don't have time to > dig into this right now ... I hope someone else does. > > Dan, if you feel like it, you're welcome to file an issue for this in > our issue tracker: https://issues.apache.org/jira/projects/SVN/issues. > I guess this means you also have a workaround now: make sure you > specify the exact on-disk casing for those absolute paths. > > -- > Johan > Hi Johan, You are absolutely correct - it is based on case of SRC. I swear I had checked casing as I've been bit before, but obviously I missed it. I did create a JIRA issue. Thanks for the support! Dan