Discussion:
SVN Move/rename doesn't appear to like absolute paths for SRC
Dan Ellis
2017-10-26 21:50:47 UTC
Permalink
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?

Thanks,
Dan
Johan Corveleyn
2017-10-27 07:06:37 UTC
Permalink
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
Dan Ellis
2017-10-27 19:36:02 UTC
Permalink
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!
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
Johan Corveleyn
2017-10-28 21:16:08 UTC
Permalink
Post by Dan Ellis
Post by Johan Corveleyn
Post by Dan Ellis
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
Dan Ellis
2017-10-30 19:35:04 UTC
Permalink
Post by Dan Ellis
Post by Dan Ellis
Post by Johan Corveleyn
Post by Dan Ellis
Hi,
I brought this up back in 2014
(https://svn.haxx.se/users/archive-2014-05/0115.shtml). I managed
to work
Post by Dan Ellis
Post by Johan Corveleyn
Post by Dan Ellis
around it but just ended up running into it again. I'm running SVN
1.8.13.
Post by Dan Ellis
Post by Johan Corveleyn
Post by Dan Ellis
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'
Post by Dan Ellis
Post by Johan Corveleyn
Post by Dan Ellis
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?
Post by Dan Ellis
Post by Johan Corveleyn
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
Post by Dan Ellis
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
[[[
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
[[[
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

Loading...