On Thu, Jul 17, 2014 at 11:23 AM, Daniel Migowski <dmigowski_at_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
Received on 2014-07-17 11:58:40 CEST