This error is about the working copy lock, not user locks. This lock makes sure
only a single operation can change (a part of) the working copy at the same
time, to avoid breaking your working copy.
The problem here is that patch locks only one working copy, but your patch
tries to change multiple working copies. (Directory externals are separate
working copies). This is a scenario that was never designed for patch.
Bert
From: Griffin Myers
Sent: Tuesday, November 4, 2014 2:56 PM
To: users@subversion.apache.org
Please Cc responses as I am not subscribed to the list.
I’m primarily a Tortoise user under Windows, but have recently needed to start
using the command line client more frequently. Our development environment
heavily leverages externals and developers often distribute patches as a means
for code review. With the command line client I’ve discovered that “svn patch”
fails with an E155005: No write-lock error when applying a patch which adds or
deletes files which span externals. I’ve observed this with both 1.7.7 and
1.8.10. I’ve had no problems when applying such patches with the Tortoise
patch mechanism. A trivial example for clarity:
Assume the following wc structure:
test1/
fileA.txt
externals/
test2/
fileB.txt
[gmyers@pc test1]$ svn -v status
2 2 gmyers .
2 2 gmyers externals
X externals/test2
2 1 gmyers fileA.txt
Performing status on external item at 'externals/test2':
1 1 gmyers
/home/gmyers/svnadmin_test/demo/test1/externals/test2
1 1 gmyers
/home/gmyers/svnadmin_test/demo/test1/externals/test2/fileB.txt
Now assume I have three patch files which perform the following operations: 1)
Add a file file2.dat to externals/test2/, 2)Delete externals/test2/fileB.txt,
3) Modify externals/test2/fileB.txt. The patches were all generated by
performing the desired task and dumping the result from svn diff.
[gmyers@pc test1]$ cat add.patch
Index: externals/test2/file2.dat
===================================================================
--- externals/test2/file2.dat (revision 0)
+++ externals/test2/file2.dat (working copy)
@@ -0,0 +1 @@
+This is file2.
[gmyers@pc test1]$ cat delete.patch
Index: externals/test2/fileB.txt
===================================================================
--- externals/test2/fileB.txt (revision 1)
+++ externals/test2/fileB.txt (working copy)
@@ -1 +0,0 @@
-This is fileB.txt
[gmyers@pc test1]$ cat modify.patch
Index: externals/test2/fileB.txt
===================================================================
--- externals/test2/fileB.txt (revision 1)
+++ externals/test2/fileB.txt (working copy)
@@ -1 +1,3 @@
This is fileB.txt
+
+Add some text.
Now I’ll attempt to apply the patches. The “add” patch returns E155005 and
although it creates the new file2.dat file it fails to add it to svn:
[gmyers@pc test1]$ svn patch add.patch
svn: E155005: No write-lock in
'/home/gmyers/svnadmin_test/demo/test1/externals/test2'
The “delete” patch returns E155005 and does nothing:
[gmyers@pc test1]$ svn patch delete.patch
svn: E155005: No write-lock in
'/home/gmyers/svnadmin_test/demo/test1/externals/test2'
The “modify” patch succeeds as expected:
[gmyers@pc test1]$ svn patch modify.patch
U externals/test2/fileB.txt
I’m wondering if this is a bug or the intended behavior? If it is intended
then what is the reasoning behind the apparent need for a lock only for
adds/deletes to externals but not for modify operations? Is there any sort of
recommended workaround for this issue?
Thanks,
Griffin Myers
