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 <dmigow...@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
