tortoisesvn status:obstructed

Question

i was doing an svn update, and a couple folders suddenly became obstructed, and cleanup was useless - it reported locks that i couldn't find or release. i ended up deleting the offending folders and cleanup worked.

i think i understand that svn wasn't able to compare subfolders or something...

my question is: how did they get that way; is it a local change that caused it, or could it have been another teammate committing something? is my svn client out of date?

Manchester

Answer 1

More than likely it had nothing to do with another teammate committing something to the SVN repository to affect your working copy.

Working copies a great innovation of Subversion, but sometimes they just break down from use and abuse and a fresh checkout is required. This can be aggravating when you have local changes.

Now obstructions can be caused by a couple of things. First, the working copy is just wonked. Its broke, cleanup won't fix it. Second, it could become obstructed because you have another window, application, or process that has a hold on a file or directory you're trying to commit. This is especially common with Windows and TortoiseSVN.

Are you sure you didn't have any command line windows, other applications, or even a windows file explorer windows pointed at those directories?

Individuality

i suppose that i very easily could have had an explorer window open on a subdirectory. i'll keep that in mind for next time. perhaps even a reboot of the windows machine could clean up any system holds/locks. thanks – Manchester

Answer 2

This can also happen when you have a symlink to the SVN directory. If you press Commit from the actual directory it's fine, but if you choose Commit on the symlink, it will say the directory is obstructed.

Fart

Answer 3

I saw this yesterday on a client machine that was trying to use a 1.4.x version of TortoiseSVN against my 1.6.x server. It was having trouble on large commits, and would eventually fail. It left the working copy in a messed up state and unable to commit, even after a cleanup.

Installing the latest version fixed it all. (still needed to blow away the obstructed working copy and check out fresh, though)

Rhynd

an update would probably be a good idea. i'll check out everybody's version numbers next time. thanks – Manchester

Answer 4

I had the same problem when trying to add to my repo a directory that was already versioned elsewhere. After deleting the svn references, The conflict resulted in obstruction.

I changed the name of the culprit folder and That did the trick I was able to add it and commit it.
Somehow ToirtoiseSVN was holding the reference of the folder name and changing it was a successful workaround.

Barytes

Answer 5

I didn't want to rename the obstructed file so I made a copy of the file elsewhere, revert the file with tortoise (I have never committed it but svn seems to have a wrong opinion about it... maybe it's because of the failed commit), then I move the copied file in the original position.

Entering in tortoise window to commit the working copy, I can see that the obstruction has been solved.

Probably the same operations can be applied for obstructed folders.

Drees