You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Daniel Migowski <dm...@ikoffice.de> on 2014/07/17 02:41:59 UTC
subversion destroys my Working Copy
Hello,
within 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. The tortoise users told me to report this to subversion directly, because they don't modify the working copy.
And just in case you wonder: Of couse I tried to cleanup the root folder C:\IKOfficeRoot, but this always tells me that cleanup doesn't succeed, and that I should do a cleanup instead...
Regards,
Daniel Migowski
Re: subversion destroys my Working Copy
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Jul 17, 2014 at 6:03 AM, Daniel Migowski <dm...@ikoffice.de> wrote:
> Hello,
>
> I have to say sorry for the noise. You were right, after retrying to cleanup my old copies of the working copy it occurred to me that subversion really can clean things up. The problem was that during my initial tests I didn't realize that Eclipse still held the lock when the editor was already closed.
>
> Sorry for that.
>
> Regards,
> Daniel Migowski
Glad you found the issue and resolved it.
My personal approach is "don't use svn:keywords", along with "don't
use svn:eol" The erratic and inconsistent contents of a working copy
based on various local settings, such as the change author or URL of
the upstream repo, and the extra overhead of "I've committed the file
and the contents will therefore be altered by the commit itself" for
revision based keywords are just begging for this kind of problem to
occur again and again and again.
The consequence of the casual legibility of such keywords is that you
have to spend resources managing keywords, disabling them, avoiding
their accidental use in source code that would have its checksums and
timestamps altered by checkins, etc. It gets very expensive at odd
times, as you just noted. It's frequent use is one of the consequences
of the evolution of Subversion from CVS, and it's one that I've found
more effective to simply reject and avoid altogether.
AW: subversion destroys my Working Copy
Posted by Daniel Migowski <dm...@ikoffice.de>.
Hello,
I have to say sorry for the noise. You were right, after retrying to cleanup my old copies of the working copy it occurred to me that subversion really can clean things up. The problem was that during my initial tests I didn't realize that Eclipse still held the lock when the editor was already closed.
Sorry for that.
Regards,
Daniel Migowski
-----Ursprüngliche Nachricht-----
Von: Johan Corveleyn [mailto:jcorvel@gmail.com]
Gesendet: Donnerstag, 17. Juli 2014 11:58
An: Daniel Migowski
Cc: Andreas Stieger; users@subversion.apache.org
Betreff: Re: subversion destroys my Working Copy
On Thu, Jul 17, 2014 at 11:23 AM, Daniel Migowski <dm...@ikoffice.de> wrote:
> Hello Andreas,
>
>
>
> my editor (current Eclipse 4.4) locks my build.xml files, even after I
> closed them in the Editor. This is a bug, alright, but nonetheless I
> feel that subversion should never leave the Working Copy in a state
> where it cannot be cleaned up anymore.
>
>
>
> I propose the following behavior as correct: Since the commit itself
> succeeded, the local file should be marked as being in the revision
> committed, but with local changes (since the tags have not been updated).
> Then I could simply fix my problems by reverting to HEAD after
> unlocking my file and everything is fine.
>
>
>
> Do you agree? This behaviors seems much better.
>
Just as a FYI, some prior discussion around a similar issue (with 'svn revert'):
http://svn.haxx.se/users/archive-2014-02/0157.shtml ("svn revert"
corrupts working copy)
From that discussion I remembered two things:
1) Your working copy isn't really corrupt. There is an obstruction (locked file in your case) that prevents svn from completing its work.
Remove the obstruction and all will be fine (after removing the obstruction running 'svn cleanup' should bring everything back into a consistent state).
2) With the current design, there is not much that can be done about this. During its operation (update, revert, ...) svn makes changes to both its database (.svn/wc.db) and the filesystem. Both parts need to be consistent with each other. Svn will first make changes to its database, and then schedule the changes it needs to make to the filesystem in its "work queue" (things that still need to be completed on the filesystem to bring the working copy in a consistent state). If some part of the work queue cannot be completed (because of an
obstruction) svn will bail out. The work queue still needs to be completed though, before anything else can be done. Running 'svn cleanup' first tries to complete the work queue, and will also bail out if it can't. The work queue *must* be completed to return the working copy to a consistent state.
--
Johan
Re: subversion destroys my Working Copy
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jul 17, 2014 at 11:23 AM, Daniel Migowski <dm...@ikoffice.de> wrote:
> Hello Andreas,
>
>
>
> my editor (current Eclipse 4.4) locks my build.xml files, even after I
> closed them in the Editor. This is a bug, alright, but nonetheless I feel
> that subversion should never leave the Working Copy in a state where it
> cannot be cleaned up anymore.
>
>
>
> I propose the following behavior as correct: Since the commit itself
> succeeded, the local file should be marked as being in the revision
> committed, but with local changes (since the tags have not been updated).
> Then I could simply fix my problems by reverting to HEAD after unlocking my
> file and everything is fine.
>
>
>
> Do you agree? This behaviors seems much better.
>
Just as a FYI, some prior discussion around a similar issue (with 'svn revert'):
http://svn.haxx.se/users/archive-2014-02/0157.shtml ("svn revert"
corrupts working copy)
>From that discussion I remembered two things:
1) Your working copy isn't really corrupt. There is an obstruction
(locked file in your case) that prevents svn from completing its work.
Remove the obstruction and all will be fine (after removing the
obstruction running 'svn cleanup' should bring everything back into a
consistent state).
2) With the current design, there is not much that can be done about
this. During its operation (update, revert, ...) svn makes changes to
both its database (.svn/wc.db) and the filesystem. Both parts need to
be consistent with each other. Svn will first make changes to its
database, and then schedule the changes it needs to make to the
filesystem in its "work queue" (things that still need to be completed
on the filesystem to bring the working copy in a consistent state). If
some part of the work queue cannot be completed (because of an
obstruction) svn will bail out. The work queue still needs to be
completed though, before anything else can be done. Running 'svn
cleanup' first tries to complete the work queue, and will also bail
out if it can't. The work queue *must* be completed to return the
working copy to a consistent state.
--
Johan
AW: subversion destroys my Working Copy
Posted by Daniel Migowski <dm...@ikoffice.de>.
Hello Andreas,
my editor (current Eclipse 4.4) locks my build.xml files, even after I closed them in the Editor. This is a bug, alright, but nonetheless I feel that subversion should never leave the Working Copy in a state where it cannot be cleaned up anymore.
I propose the following behavior as correct: Since the commit itself succeeded, the local file should be marked as being in the revision committed, but with local changes (since the tags have not been updated). Then I could simply fix my problems by reverting to HEAD after unlocking my file and everything is fine.
Do you agree? This behaviors seems much better.
Regards,
Daniel Migowski
Von: Andreas Stieger [mailto:andreas.stieger@gmx.de]
Gesendet: Donnerstag, 17. Juli 2014 07:44
An: Daniel Migowski
Cc: users@subversion.apache.org
Betreff: Re: subversion destroys my Working Copy
Hi,
On 17 Jul 2014, at 02:41, Daniel Migowski <dm...@ikoffice.de>> wrote:
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
Environmental problem, the file is locked. Which editor are you using? Does your editor lock files in a way that is incompatible with modifications via keywords? Does the same happen if you close the editor when committing?
I beg you to fix that because it is really time consuming and annoying having to check out gigabytes again and again.
There is ways around that, including partial checkout. Also working copies are portable and can be cloned.
And just in case you wonder: Of couse I tried to cleanup the root folder C:\IKOfficeRoot, but this always tells me that cleanup doesn’t succeed, and that I should do a cleanup instead…
As above, check if your environment locks files in ways that would cause his behaviour.
Andreas
Re: subversion destroys my Working Copy
Posted by Andreas Stieger <an...@gmx.de>.
Hi,
> On 17 Jul 2014, at 02:41, Daniel Migowski <dm...@ikoffice.de> wrote:
>
> 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
Environmental problem, the file is locked. Which editor are you using? Does your editor lock files in a way that is incompatible with modifications via keywords? Does the same happen if you close the editor when committing?
> I beg you to fix that because it is really time consuming and annoying having to check out gigabytes again and again.
There is ways around that, including partial checkout. Also working copies are portable and can be cloned.
> And just in case you wonder: Of couse I tried to cleanup the root folder C:\IKOfficeRoot, but this always tells me that cleanup doesn’t succeed, and that I should do a cleanup instead…
As above, check if your environment locks files in ways that would cause his behaviour.
Andreas