On 16 July 2014 08:54, Daniel Migowski <dmigowski_at_ikoffice.de> wrote:
> 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
>
> Gavin Lambert 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 Lambert 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).
Hi Daniel,
Sorry to hear about your problems with working copy breakage. You will
have to ask about this on the Subversion users mailing list instead.
TortoiseSVN doesn't touch the working copy internals itself but uses
the Subversion library to do it, so any fix would have to be applied
in the Subversion library itself, not in TortoiseSVN.
Simon
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3085242
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-07-16 11:21:49 CEST