Svn error working copy locked

Found an issue with this document? Highlight the area, then use Ctrl+Enter to report it.

We’re sorry to hear the article wasn’t helpful to you.
Could you take a moment to tell us why?

You are reporting an issue with the following selected text
and/or image within the active document:

Содержание

1. Working copy locked svn error
2. The Three Meanings of “ Lock ”
3. How Locking Works in Subversion
4. Important
5. Getting a Lock

I get this error when I do an svn update:

Working copy XXXXXXXX locked Please
execute «Cleanup» command

When I run cleanup, I get

Cleanup failed to process the
following paths: XXXXXXXX

How do I get out of this loop?

One approach would be to:

1. Copy edited items to another location.
2. Delete the folder containing the problem path.
3. Update the containing folder through Subversion.
4. Copy your files back or merge changes as needed.
5. Commit

Another option would be to delete the top level folder and check out again. Hopefully it doesn’t come to that though.

For me, the trick was to run svn cleanup at the top of my working copy, not in the folder where I’d been working the whole time before the problem occurred.

Look in your .svn folder, there will be a file in it called lock. Delete that file and you will be able to update. There may be more lock files in the .svn directory of each subdirectory. They will need deleting also. This could be done as a batch quite simply from the command line with e.g.

find . -name 'lock' -exec rm -v {} ;

Note that you are manually editing files in the .svn folder. They have been put there for a reason. That reason might be a mistake, but if not you could be damaging your local copy.

SOURCE : http://www.svnforum.org/2017/viewtopic.php?p=6068

In my case I solved it by manually deleting a record in the SQLite «.svnwc» file lock record in the WC_LOCK table.

I opened the «WC» file with SQLite editor and executed

delete from WC_LOCK

Following eakkas’s comment, you might need to delete all the entries from WORK_QUEUE table as well.

Easiest way ever:

1. Go to Parent directory(Folder) of Project.
2. Pres Right click
3. Press on TortoiseSVN then Press Clean up…
4. Clean up dialog would appear automatically
5. Select Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays, Include externals
6. Pres OK

You did your job successfully.

Check the screen shots for your reference.

First step:

Second step:
Enable the Break lock option(second check box in cleanup popup window)

Hope this will help you a lot.

A colleague at work constantly sees this message, and for him it’s because he deleted a directory under SVN version control without deleting it from SVN, and then created a new directory in its place not under version control, with the same name.

If this is your problem…:

There are different ways to fix it, depending on how/why the directory was replaced.

Either way, you will likely need to:

A) Rename the existing directory to a temporary name

B) Do an SVN revert to recover the directory deleted from the file system, but not from SVN

From there, you would either

A) Copy the relevant files into the directory that was deleted

B) If you had a significant change of contents in the directory, do an SVN delete on the original, commit, and rename your new directory back to the desired name, followed by an SVN add to get that one under version control.

For me none of the above solutions worked.
I found a solution by breaking locks.
When I performed svn cleanup, I selected «Break Locks» along with «Clean up working copy status».

This one worked for me.

1. Go to the root folder,
2. Right click and cleanup
3. Check all available options
4. Press ok

After clean up it will allow you to update to the latest version.

For me, it was actually Tortoise’s fault, sort of. Tortoise just complained «cannot clean up, run clean up», but when I ran the command line (svn cleanup), it clearly told me that it couldn’t delete some files that were in use, the solution to which was obvious. Once I closed Visual Studio (which was keeping the files open), then the cleanup worked fine.

Other programs can also keep files open in the repo causing this issue. Excel holding an xls open was a culprit in another instance so it may be wise to close all programs that may be using anything in the repo or even rebooting to force programs to close out and then trying cleanup again.

I had this problem because external folders do not want to be linked into an existing folder. If you add an svn:externals property line where the destination is an existing (versioned or non-versioned) folder, you will get the SVN Woring Copy locked error. Here a cleanup will also tell you that everthing is all right but still updating won’t work.

Solution: Delete the troubling folder from the repository and make an update in the root folder where the svn:externals property is set. This will create the folder and all will be fine again.

This problem arose for me because svn:externals for files requires the destination folder to be version controlled. After I noticed that this doesn’t work across different repositories, I swaped from external files to external folder and got into this mess.

The easiest way to do this is show hidden folders and then open the .SVN folder. You should see a zero KB file named «lock» deleting this will fix the problem

I came across the exact same issue using SVN 1.7 and none of the fixes mentioned above worked.

Foremost, make sure you backup all your edited content.

After spending a couple of hours (didn’t redownload everything as my branch is over 6gb in size), I found that there is a db file called «wc» in the .svn folder of your branch.

Open up the db file using any db manager (i used firefox’s sqlite manager plugin) and navigate to WC_LOCK table. This table will have the entries for the acquired locks. Delete the records from the table and you’re done

When i have this problem, i find running the cleanup command directly on the problem path generally seems to work. Then I’ll run cleanup from the working root again, and it’ll complain about some other directory. and i just repeat until it stops complaining.

If you’re on a Windows machine, View the repository through a browser and you may well see two files with the same filename but using different cases. Subversion is case sensitive and Windows isn’t so you can get a lock when Windows thinks it’s pulling down the same file and Subversion doesn’t. Delete the duplicate file names on the repository and try again.

I did it by just creating a new folder, checking out the project, copying the updated files to the new folder.

It was fixed with a fresh checkout.

Are you using TortoiseSVN and just upgraded? I’ve had that problem before when moving from 1.4 to 1.5 and not rebooting. (Try a reboot).

The reason you need to reboot is because the cache file gets all funky.

Otherwise, to just move on, export that working copy into a new folder (don’t copy the .svn hidden folders), re-checkout the project, and move all your code back, then proceed with your commit.

just delete the .svn folders, then run a cleanup on the parent directory. Works perfectly!!

In Versions under Mac OS:
Action -> Cleanup working copy locks at…

I often get such an issue. My pattern that causes cleanup problems.

1. I open image file in viewer.
2. I delete image file/folder.
3. I am trying to commit/update

Closing image viewer where deleted file is opened solves the problem.
Maybe other software can block cleanup the same way.

In general. I believe restarting computer may help in such cases.

SVN normally updates its internal structure (.svn/prop-base) of the files in a folder before the actual files is fetched from repository. Once the files are fetched this will be cleared up. Frequently the error is thrown because the «update» failed or prematurely cancelled during the update progress.

1. Check any files are listed under .svn/prop-base directory
2. Remove any files which are not under the folder
3. Cleanup
4. Update

Now the update should work.

Had the same problem because I exported a folder under a version-controlled folder. Had to delete the folder from TortoiseSVN, then delete the folder from the filesystem (TortoiseSVN does not like unversioned subfolders … why not???)

Start Search….Lock…Select all files listed and delete..fixed

the following should do:

svn status | grep «. L» | sed ‘s/.* (.*)$/1/’ | awk ‘{print length($1),$1}’ | sort -nr | awk ‘{print «pushd » $2 «; svn cleanup ; popd»}’ | sh

Do not delete your solution!

in the .svn folder you have a file called lock it is 0 bytes long

You can delete all these files from all the .svn folders in your solution and it will work

It worked in my case

In-place unversioning of the files, and a fresh checkout into the same location, has solved this problem for me.

In TortoiseSVN, to do an in-place unversioning, right-drag the root folder of the working copy from the file list onto itself in the directory tree, and choose «SVN Export versioned items here» from the pop-up menu. TortoiseSVN notices that the destination is the same as the source, and suggests unversioning the working copy.

After unversioning, do a fresh checkout into the same folder (which now contains an unversioned copy of all the files you had). TortoiseSVN will warn you that you are checking out into an existing folder, but you can go ahead.

After this, cleanups, updates and other operations worked without a hitch. Since both of the above steps preserve local modifications, there should not be any loss of information (but backing the working copy up before this may nevertheless be a good idea).

One warning: If the working copy contains mixed versions or uncommitted property changes, that information WILL be lost. For me, this is not a common occurrence, and given the choice of a corrupt working copy or losing uncommitted property changes, I tend to opt for the latter.

I had this problem where the «clean up» worked, but the «update» would continue to fail. The solution that worked was to delete the folder in question via Windows Explorer, not TortoiseSVN’s delete (which marks the deletion as something to commit to the repository, and then I did a «checkout» to essentially «update» the folder from the respository.

More info on the difference between an O/S delete and an SVN delete here:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

Notably:

When you TortoiseSVN → Delete a file, it is removed from your working copy immediately as well as being marked for deletion in the repository on next commit.

And:

If a file is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those files and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing file and replace it with the latest version from the repository.

If you’re on Linux, try this:

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

Then run the cleanup command on that directory, then try to update.

I did the following to fix my issue:

1. Renamed the offending folder by placing an «_» in front of the
   folder name.
2. Did a «Clean Up» of the parent folder.
3. Renamed the offending folder back to it original name.
4. Did a commit.

In solution explorer, right click on the project, in the opening sub-menu click on subversion and select clean-up. It will solve the problem, as it did for me. Hope it will work.

To do the clean up

1. Delete the .svn folder.

2. Do the svncheckout in the root folder.

3. Try performing the clean up operation.

This got my issue resolved.

In the Subversion repository, a
lock is a piece of metadata that
grants exclusive access to one user to change a file. This
user is said to be the lock owner.
Each lock also has a unique identifier, typically a long
string of characters, known as the lock
token. The repository manages locks, ultimately
handling their creation, enforcement, and removal. If any
commit transaction attempts to modify or delete a locked file
(or delete one of the parent directories of the file), the
repository will demand two pieces of information—that
the client performing the commit be authenticated as the lock
owner, and that the lock token has been provided as part of
the commit process as a form of proof that the client knows which
lock it is using.

To demonstrate lock creation, let’s refer back to
our example of multiple graphic designers working on the same
binary image files. Harry has decided to change a JPEG image.
To prevent other people from committing changes to the file
while he is modifying it (as well as alerting them that he is
about to change it), he locks the file in the repository using
the svn lock command.

$ svn lock banana.jpg -m "Editing file for tomorrow's release."
'banana.jpg' locked by user 'harry'.
$

The preceding example demonstrates a number of new things.
First, notice that Harry passed the
--message (-m) option to
svn lock. Similar to svn
commit, the svn lock command can
take comments—via either --message
(-m) or --file
(-F)—to describe the reason for locking the
file. Unlike svn commit, however,
svn lock will not demand a message by
launching your preferred text editor. Lock comments are
optional, but still recommended to aid communication.

Second, the lock attempt succeeded. This means that the
file wasn’t already locked, and that Harry had the latest
version of the file. If Harry’s working copy of the file had
been out of date, the repository would have rejected the
request, forcing Harry to svn update and
reattempt the locking command. The locking command would also
have failed if the file had already been locked by someone
else.

As you can see, the svn lock command
prints confirmation of the successful lock. At this point,
the fact that the file is locked becomes apparent in the
output of the svn status and svn
info reporting subcommands.

$ svn status
     K  banana.jpg

$ svn info banana.jpg
Path: banana.jpg
Name: banana.jpg
Working Copy Root Path: /home/harry/project
URL: http://svn.example.com/repos/project/banana.jpg
Relative URL: ^/banana.jpg
Repository Root: http://svn.example.com/repos/project
Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 2198
Node Kind: file
Schedule: normal
Last Changed Author: frank
Last Changed Rev: 1950
Last Changed Date: 2006-03-15 12:43:04 -0600 (Wed, 15 Mar 2006)
Text Last Updated: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Properties Last Updated: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Checksum: 3b110d3b10638f5d1f4fe0f436a5a2a5
Lock Token: opaquelocktoken:0c0f600b-88f9-0310-9e48-355b44d4a58e
Lock Owner: harry
Lock Created: 2006-06-14 17:20:31 -0500 (Wed, 14 Jun 2006)
Lock Comment (1 line):
Editing file for tomorrow's release.

$

The fact that the svn info command,
which does not contact the repository when run against working
copy paths, can display the lock token reveals an important
piece of information about those tokens: they are cached in
the working copy. The presence of the lock token is critical.
It gives the working copy authorization to make use of the
lock later on. Also, the svn status
command shows a K next to the file (short
for locKed), indicating that the lock token is present.

Now that Harry has locked banana.jpg,
Sally is unable to change or delete that file:

$ svn delete banana.jpg
D         banana.jpg
$ svn commit -m "Delete useless file."
Deleting       banana.jpg
svn: E175002: Commit failed (details follow):
svn: E175002: Server sent unexpected return value (423 Locked) in response to 
DELETE request for '/repos/project/!svn/wrk/64bad3a9-96f9-0310-818a-df4224ddc
35d/banana.jpg'
$

But Harry, after touching up the banana’s shade of yellow,
is able to commit his changes to the file. That’s because he
authenticates as the lock owner and also because his working
copy holds the correct lock token:

$ svn status
M    K  banana.jpg
$ svn commit -m "Make banana more yellow"
Sending        banana.jpg
Transmitting file data .
Committed revision 2201.
$ svn status
$

Notice that after the commit is finished, svn
status shows that the lock token is no longer
present in the working copy. This is the standard behavior of
svn commit—it searches the working
copy (or list of targets, if you provide such a list) for
local modifications and sends all the lock tokens it
encounters during this walk to the server as part of the
commit transaction. After the commit completes successfully,
all of the repository locks that were mentioned are
released—even on files that weren’t
committed. This is meant to discourage users from
being sloppy about locking or from holding locks for too long.
If Harry haphazardly locks 30 files in a directory named
images because he’s unsure of which files
he needs to change, yet changes only four of those files, when he
runs svn commit images, the process will
still release all 30 locks.

This behavior of automatically releasing locks can be
overridden with the --no-unlock option to
svn commit. This is best used for those
times when you want to commit changes, but still plan to make
more changes and thus need to retain existing locks. You can
also make this your default behavior by setting the
no-unlock runtime configuration option (see
the section called “Runtime Configuration Area”).

Of course, locking a file doesn’t oblige one to
commit a change to it. The lock can be released at any time
with a simple svn unlock command:

$ svn unlock banana.c
'banana.c' unlocked.

When a commit fails due to someone else’s locks, it’s
fairly easy to learn about them. The easiest way is to run
svn status -u:

$ svn status -u
M               23   bar.c
M    O          32   raisin.jpg
        *       72   foo.h
Status against revision:     105
$

In this example, Sally can see not only that her copy of
foo.h is out of date, but also that one of the
two modified files she plans to commit is locked in the
repository. The O symbol stands for
“Other,” meaning that a lock exists on the file
and was created by somebody else. If she were to attempt a
commit, the lock on raisin.jpg would
prevent it. Sally is left wondering who made the lock, when,
and why. Once again, svn info has the
answers:

$ svn info ^/raisin.jpg
Path: raisin.jpg
Name: raisin.jpg
URL: http://svn.example.com/repos/project/raisin.jpg
Relative URL: ^/raisin.jpg
Repository Root: http://svn.example.com/repos/project
Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 105
Node Kind: file
Last Changed Author: sally
Last Changed Rev: 32
Last Changed Date: 2006-01-25 12:43:04 -0600 (Sun, 25 Jan 2006)
Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Lock Owner: harry
Lock Created: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Lock Comment (1 line):
Need to make a quick tweak to this image.
$

Just as you can use svn info to examine
objects in the working copy, you can also use it to examine
objects in the repository. If the main argument to
svn info is a working copy path, then all
of the working copy’s cached information is displayed; any
mention of a lock means that the working copy is holding a
lock token (if a file is locked by another user or in another
working copy, svn info on a working copy
path will show no lock information at all). If the main
argument to svn info is a URL, the
information reflects the latest version of an object in the
repository, and any mention of a lock describes the current
lock on the object.

So in this particular example, Sally can see that Harry
locked the file on February 16 to “make a quick
tweak.” It being June, she suspects that he probably
forgot all about the lock. She might phone Harry to complain
and ask him to release the lock. If he’s unavailable, she
might try to forcibly break the lock herself or ask an
administrator to do so.

A repository lock isn’t sacred—in Subversion’s
default configuration state, locks can be released not only by
the person who created them, but by anyone. When somebody
other than the original lock creator destroys a lock, we refer
to this as breaking the lock.

From the administrator’s chair, it’s simple to break
locks. The svnlook
and svnadmin programs have the ability to
display and remove locks directly from the repository. (For
more information about these tools, see
the section called “An Administrator’s Toolkit”.)

$ svnadmin lslocks /var/svn/repos
Path: /project2/images/banana.jpg
UUID Token: opaquelocktoken:c32b4d88-e8fb-2310-abb3-153ff1236923
Owner: frank
Created: 2006-06-15 13:29:18 -0500 (Thu, 15 Jun 2006)
Expires: 
Comment (1 line):
Still improving the yellow color.

Path: /project/raisin.jpg
UUID Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Owner: harry
Created: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Expires: 
Comment (1 line):
Need to make a quick tweak to this image.

$ svnadmin rmlocks /var/svn/repos /project/raisin.jpg
Removed lock on '/project/raisin.jpg'.
$

The more interesting option is to allow users to break
each other’s locks over the network. To do this, Sally simply
needs to pass the --force option to the
svn unlock command:

$ svn status -u
M               23   bar.c
M    O          32   raisin.jpg
        *       72   foo.h
Status against revision:     105
$ svn unlock raisin.jpg
svn: E195013: 'raisin.jpg' is not locked in this working copy
$ svn info raisin.jpg | grep ^URL
URL: http://svn.example.com/repos/project/raisin.jpg
$ svn unlock http://svn.example.com/repos/project/raisin.jpg
svn: warning: W160039: Unlock failed on 'raisin.jpg' (403 Forbidden)
$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
'raisin.jpg' unlocked.
$

Now, Sally’s initial attempt to unlock failed because she
ran svn unlock directly on her working copy
of the file, and no lock token was present. To remove the
lock directly from the repository, she needs to pass a URL
to svn unlock. Her first attempt to unlock
the URL fails, because she can’t authenticate as the lock
owner (nor does she have the lock token). But when she
passes --force, the authentication and
authorization requirements are ignored, and the remote lock is
broken.

Simply breaking a lock may not be enough. In
the running example, Sally may not only want to break Harry’s
long-forgotten lock, but relock the file for her own use.
She can accomplish this by using svn unlock
with --force and then svn lock
back-to-back, but there’s a small chance that somebody else
might lock the file between the two commands. The simpler thing
to do is to steal the lock, which involves
breaking and relocking the file all in one atomic step. To
do this, Sally passes the --force option
to svn lock:

$ svn lock raisin.jpg
svn: warning: W160035: Path '/project/raisin.jpg' is already locked by user 'h
arry' in filesystem '/var/svn/repos/db'
$ svn lock --force raisin.jpg
'raisin.jpg' locked by user 'sally'.
$

In any case, whether the lock is broken or stolen,
Harry may be in for a surprise. Harry’s working copy still
contains the original lock token, but that lock no longer
exists. The lock token is said to
be defunct. The lock represented by
the lock token has either been broken (no longer in the
repository) or stolen (replaced with a different lock).
Either way, Harry can see this by asking
svn status to contact the
repository:

$ svn status
     K  raisin.jpg
$ svn status -u
     B          32   raisin.jpg
Status against revision:     105
$ svn update
Updating '.':
  B  raisin.jpg
Updated to revision 105.
$ svn status
$

If the repository lock was broken, then svn
status --show-updates (-u)
displays a B (Broken) symbol next to the
file. If a new lock exists in place of the old one, then a
T (sTolen) symbol is shown. Finally,
svn update notices any defunct lock tokens
and removes them from the working copy.

We’ve seen how svn lock
and svn unlock can be used to create,
release, break, and steal locks. This satisfies the goal of
serializing commit access to a file. But what about the
larger problem of preventing wasted time?

For example, suppose Harry locks an image file and then
begins editing it. Meanwhile, miles away, Sally wants to do
the same thing. She doesn’t think to run svn status
-u, so she has no idea that Harry has
already locked the file. She spends hours editing the file,
and when she tries to commit her change, she discovers that
either the file is locked or that she’s out of date.
Regardless, her changes aren’t mergeable with Harry’s. One of
these two people has to throw away his or her work, and a lot of
time has been wasted.

Subversion’s solution to this problem is to provide a
mechanism to remind users that a file ought to be locked
before the editing begins. The mechanism
is a special property: svn:needs-lock. If
that property is attached to a file (regardless of its value,
which is irrelevant), Subversion will try to use
filesystem-level permissions to make the file read-only—unless,
of course, the user has explicitly locked the file.
When a lock token is present (as a result of using
svn lock), the file becomes read/write.
When the lock is released, the file becomes read-only
again.

The theory, then, is that if the image file has this
property attached, Sally would immediately notice
something is strange when she opens the file for editing:
many applications alert users immediately when a read-only
file is opened for editing, and nearly all would
prevent her from saving changes to the file. This
reminds her to lock the file before editing, whereby she
discovers the preexisting lock:

$ /usr/local/bin/gimp raisin.jpg
gimp: error: file is read-only!
$ ls -l raisin.jpg
-r--r--r--   1 sally   sally   215589 Jun  8 19:23 raisin.jpg
$ svn lock raisin.jpg
svn: warning: W160035: Path '/project/raisin.jpg' is already locked by user 'h
arry' in filesystem '/var/svn/repos/db'
$ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Lock Owner: harry
Lock Created: 2006-06-08 07:29:18 -0500 (Thu, 08 June 2006)
Lock Comment (1 line):
Making some tweaks.  Locking for the next two hours.
$

Note that this property is a communication tool that
works independently from the locking system. In other words,
any file can be locked, whether or not this property is
present. And conversely, the presence of this property
doesn’t make the repository require a lock when
committing.

Unfortunately, the system isn’t flawless. It’s possible
that even when a file has the property, the read-only reminder
won’t always work. Sometimes applications misbehave and
“hijack” the read-only file, silently allowing
users to edit and save the file anyway. There’s not much that
Subversion can do in this situation—at the end of the
day, there’s simply no substitution for good interpersonal
communication.^[30]