Tortoise SVN destroys my Working Copy

Hello,

Sorry for reposting, but since the mailinglist doesn't sent me the answers that others give back, I have nothing to reply to. My Problem:

with 2 days TortoiseSVN destroyed my Working Copy six times. This always occurs when I commit a resource already open in an editor which contains a @revision tag. The commit message looks like this:

C:\IKOfficeRoot\Java\ERP\Core\build.xml
C:\IKOfficeRoot\Java\ERP\Framework\data\templates\customer-build-template.xml
C:\IKOfficeRoot\Java\ERP\Core\build.xml
C:\IKOfficeRoot\Java\ERP\Framework\data\templates\customer-build-template.xml
At revision: 28113
Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
Failed to run the WC DB work queue associated with 'C:\IKOfficeRoot', work item 48025 (file-commit Java/ERP/Core/build.xml)
Can't move 'C:\IKOfficeRoot\.svn\tmp\svn-F4D69508' to 'C:\IKOfficeRoot\Java\ERP\Core\build.xml': Zugriff verweigert

After that I try to do a cleanup but that fails, recommending me to do a cleanup. It seemed that Tortoise managed to handle that once, when I committed a single other build.xml file before, but when I tried to commit the two ones above, the cleanup didn't succeed, so when you try to reproduce, please don't just try this once. My version information is:

TortoiseSVN 1.8.7, Build 25475 - 64 Bit , 2014/05/05 20:52:12
Subversion 1.8.9, -release
apr 1.5.1
apr-util 1.5.3
serf 1.3.5
OpenSSL 1.0.1g 7 Apr 2014
zlib 1.2.8

I beg you to fix that because it is really time consuming and annoying having to check out gigabytes again and again.

Gavin Lamberts pointet out that:

The solution to that seems obvious: either remove the @revision tags from the files (they're not that useful in the first place), remember to close the file first, or stop using editors that lock the file being edited.

I don't see it like that. TortoiseSVN should behave something like that: The result should be that the file version is the one created in SVN during the commit to, say, revision 1000, then my local version of the file should be revision 1000, but just have local modifications. I then could simply "revert" my local changes after closing the editor, and have exactly the file Tortoise wanted me to have in the first place. In fact, I really don't care how the exact workaround for this problem is, but I simply don't want to wear out my SSDs by having to checkout 20 Gigs over and over again because the Working Copy is broken.

Gavin Lamberts also kindly suggested ways to fix the problem:

Did you clean up after closing the file in the editor? Also, did the cleanup actually fail or did it report success but not get the correct version of build.xml? Because in the latter case, you should be able to Update to fix it (as long as you've closed the editor first).

Of course I did, but cleanup fails and suggests me to cleanup again, even when all editors are already closed, and no other file has a lock.

Btw. Tortoise shouldn't brake the Working copy ever, as we all can agree. And this never happened when I was on a previous version (1.5? Don't know for sure).

Regards,
Daniel Migowski

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3085241

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-07-16 09:54:35 CEST