"Cedric Williams" <CedWilli@tceq.state.tx.us> writes:
> 5 - After the commit succeeded, svn changed the .svn/entries file to
> have the checksum information for the checked-in version of the
> script (which has the $Id$ tag, though not expanded since the
> repository stores the tag info in the props)
> 6 - Then svn tried to replace the current WC version with the
> repository version + expanded tag - **this failed** (script was in
> use at the time and could not be overwritten - but this was not the
> real problem)
> 7 - svn failed, notified the bonehead user, and quit
> 8 - svn never copied the repository version to .svn/text-base, but
> left the prior version of the script (now revision HEAD - 2) THIS
> was the real problem - the .svn/entries file had the checksum for
> the HEAD - 1 copy, but .svn/text-base had the version of the file
> prior to that on the drive
[...]
> A - Should svn handle the move-previous-to-text-base before trying
> to do keyword expansion (since that might fail)?
> B - Should svn cleanup be able to recognize / handle the situation
> when a checkin hasn't completed moving files around, and implement
> (or suggest) some strategy to get the .svn directory back in shape?
After the failed commit was the working copy locked, that's a
Subversion lock where 'svn st' shows state 'L'?
In principle Subversion's log file mechanism should have meant that
the failed commit left the working copy locked. However I think I see
a bug that would have unlocked the working copy. Look at the
svn_wc_adm_close at the end of svn_client_commit, that will have the
effect of removing the lock even if an error occurred. There is a
comment there (one I think I added when I did the access baton
conversion) questioning the logic. I think the correct behaviour in
your case would be for the lock, and log file, to remain. Then there
is a chance that 'svn cleanup' would have fixed the working copy.
I don't really understand why there is special 'cleanup:' handling in
svn_client_commit, I guess it is to ensure that a failed commit always
calls abort_edit. Anyone know the history? I think it is an error
both to remove the locks, and to clear the temporary files, if a
commit error occurs.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 26 03:45:10 2003