Bugreport
Hello, TortoiseSVN asked me to send this bugreport. I currently experienced connection issues so this might be network related. --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db.c' line 8713: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK --- Regards, Daniel Migowski
AW: Bugreport
Thanks, I will! -Ursprüngliche Nachricht- Von: Andreas Stieger [mailto:andreas.stie...@gmx.de] Gesendet: Donnerstag, 11. Juni 2015 21:44 An: Daniel Migowski Cc: users@subversion.apache.org Betreff: Re: Bugreport Hello, On 11/06/15 21:42, Daniel Migowski wrote: > TortoiseSVN asked me to send this bugreport. I currently experienced > connection issues so this might be network related. [... > 'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db.c' > > line 8713: assertion failed (svn_dirent_is_absolute(local_abspath)) Please upgrade to the latest compatible TortoiseSVN 1.8.11 (containing Subversion 1.8.13) and try again. Andreas
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
AW: subversion destroys my Working Copy
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.stie...@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 mailto:dmigow...@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
AW: subversion destroys my Working Copy
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:jcor...@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 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
