subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bert Huijben <b...@qqmail.nl>
Subject Re: Why does svn patch fail for externals on add/delete?
Date Tue, 04 Nov 2014 14:47:59 GMT
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
Mime
View raw message