Commit failure and KILLME file.

[Martin Tomes <li...@tomes.org>]

Copied to the Subversion dev list as this is probably a core Subversion issue.

We just had a commit fail with a message saying that a directory was not locked.  Actually, the 
commit succeeded but the update of the working copy failed.  When we tried an svn cleanup it refused 
to clean up saying it couldn't open KILLME because it exists.  Having removed that file and done a 
cleanup and update we are left with a lot of binary files which are flagged as having a conflict 
when it looks like they don't (the repository version does match the working copy file).

The directory which was not locked was inside another directory which was being deleted.

This is bad, and there is no obvious way to recover.  Files which were added and changed are still 
shown as being added/changed in the working copy even though they are in the repository.  The only 
option appears to be a new checkout and then a long laborious check to make sure all the changes did 
get committed.

What is the best way out of this?

Is this a known problem or is a new Issue required?

-- 
Martin Tomes
echo 'Martin x Tomes at controls x eurotherm x co x uk'\
  | sed -e 's/ x /\./g' -e 's/ at /@/'


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Commit failure and KILLME file.

[kf...@collab.net]

Martin Tomes <li...@tomes.org> writes:
> We just had a commit fail with a message saying that a directory was
> not locked.  Actually, the commit succeeded but the update of the
> working copy failed.  When we tried an svn cleanup it refused to clean
> up saying it couldn't open KILLME because it exists.  Having removed
> that file and done a cleanup and update we are left with a lot of
> binary files which are flagged as having a conflict when it looks like
> they don't (the repository version does match the working copy file).

When you say "the update", what do you mean?  (Since update is not
part of commit, although some metadata about the committed targets is
changed).

> The directory which was not locked was inside another directory
> which was being deleted.

Concrete examples (i.e., transcripts) are preferable, if you still
have the information.

> This is bad, and there is no obvious way to recover.  Files which were
> added and changed are still shown as being added/changed in the
> working copy even though they are in the repository.  The only option
> appears to be a new checkout and then a long laborious check to make
> sure all the changes did get committed.

Sorry this happened to you!  But, that shouldn't be long and
laborious, it should be easy -- just write a small script to do the
appropriate comparisons.  No one should ever have to do such a
comparison by hand.

> What is the best way out of this?
> 
> Is this a known problem or is a new Issue required?

I don't think it's known; anyway we'd need more details (the
transcript, or at least the current working copy) to file an issue.

-Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Commit failure and KILLME file.

[Philip Martin <ph...@codematters.co.uk>]

Martin Tomes <li...@tomes.org> writes:

> When we tried an svn cleanup it refused to clean up saying it
> couldn't open KILLME because it exists.

Already fixed on the trunk (r8891).

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Commit failure and KILLME file.

[Ben Collins-Sussman <su...@collab.net>]

Martin Tomes wrote:

> What is the best way out of this?

In general, if a commit succeeds on the server but then the client never 
hears about the success (or if the client utterly fails to perform 
"post-update" maintenance on the working copy), then you're left in a 
situation much like yours:  the working copy still thinks all the files 
are locally changed.  When you update, of course you get the *same* 
changes sent back from the server, so everything gets conflicted.

Really, the best thing to do is a fresh checkout.  An alternate strategy 
is to toss all local mods ('svn revert -R'), delete any leftover 
unversioned files that result, and then run 'svn up'.

The important question here, however, isn't "how do I make the working 
copy happy again?", but rather,  "how and why did the post-commit 
processing fail in the first place?"  Any extra detail or reproduction 
info about that would be great.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org