Hello,
What follows is a reproducible test-cast to get your working copy into
an unfixable state.
willow:~/tmp/test svn st
willow:~/tmp/test ls
a.txt
willow:~/tmp/test svn cp a.txt b.txt
A b.txt
willow:~/tmp/test svn cp a.txt c.txt
A c.txt
willow:~/tmp/test rm b.txt
willow:~/tmp/test svn st
! + b.txt
A + c.txt
willow:~/tmp/test svn commit -m "Problem commit."
Adding b.txt
Adding c.txt
svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: In directory '/Users/scelis/tmp/test'
svn: Error processing command 'committed' in '/Users/scelis/tmp/test'
svn: Error replacing text-base of 'b.txt'
svn: Can't open file '/Users/scelis/tmp/test/b.txt': No such file or directory
willow:~/tmp/test svn st
L .
! + b.txt
A + c.txt
willow:~/tmp/test svn unlock .
svn: '/Users/scelis/tmp' is not a working copy
willow:~/tmp/test svn cleanup
svn: In directory '.'
svn: Error processing command 'committed' in '.'
svn: Can't move '.svn/props/b.txt.svn-work' to
'.svn/prop-base/b.txt.svn-base': No such file or directory
willow:~/tmp/test svn revert b.txt
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
First, please note the versions of Subversion that I am using.
Server Version:
1.4.4 (r25188).
Client Version:
willow:~ svn --version
svn, version 1.5.0 (Release Candidate 5)
compiled May 5 2008, 09:28:47
Looking back at the transcript above, there are two potential issues that I see.
1) The commit succeeds and checks in b.txt even though b.txt is no
longer in my working copy. Should that be how it works? I would
expect the entire commit to fail, or at least for b.txt to not be
checked in.
2) Once the commit has succeeded, there is no way to fix my working
copy to get back to a normal state. One big culprit of this is the
fact that 'svn unlock .' fails saying that the parent directory is not
a working copy. This is true, however the directory I tried to unlock
definitely is a working copy directory. The other big culprit is that
'svn cleanup' complains about a file down under the .svn directory.
I tried to replicate this using a 1.4.6 client and saw similar issues.
However, with a little voodoo I was able to fix the working copy. It
went like this:
willow:~/tmp/test svn st
willow:~/tmp/test ls
a.txt
willow:~/tmp/test svn cp a.txt b.txt
A b.txt
willow:~/tmp/test svn cp a.txt c.txt
A c.txt
willow:~/tmp/test rm b.txt
willow:~/tmp/test svn st
! + b.txt
A + c.txt
willow:~/tmp/test svn commit -m "Problem commit."
Adding b.txt
Adding c.txt
svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: In directory '/Users/scelis/tmp/test'
svn: Error processing command 'committed' in '/Users/scelis/tmp/test'
svn: Error replacing text-base of 'b.txt'
svn: Can't open file '/Users/scelis/tmp/test/b.txt': No such file or directory
willow:~/tmp/test svn st
L .
! + b.txt
A + c.txt
willow:~/tmp/test svn unlock .
svn: Working copy '/Users/scelis/tmp/test' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
willow:~/tmp/test svn cleanup
svn: In directory '.'
svn: Error processing command 'committed' in '.'
svn: Error replacing text-base of 'b.txt'
svn: Can't open file 'b.txt': No such file or directory
willow:~/tmp/test touch b.txt
willow:~/tmp/test svn cleanup
willow:~/tmp/test svn status
M b.txt
A + c.txt
willow:~/tmp/test svn revert b.txt
Reverted 'b.txt'
willow:~/tmp/test svn status
A + c.txt
willow:~/tmp/test svn update
svn: Failed to add file 'c.txt': object of the same name already exists
willow:~/tmp/test svn status
! .
A + c.txt
willow:~/tmp/test svn revert c.txt
Reverted 'c.txt'
willow:~/tmp/test svn status
? c.txt
! .
willow:~/tmp/test rm c.txt
willow:~/tmp/test svn update
willow:~/tmp/test svn status
As you can see, in this situation 'svn cleanup' complains about just
b.txt instead of the file under .svn. This led me down a path which
eventually fixed my working copy, even though it wasn't pretty.
Am I right in thinking that there are one or two bugs here? I
understand that I should have run 'svn revert b.txt' instead of 'rm
b.txt'. However, I still feel that my mistake shouldn't have caused
the trouble that it did.
Thank you for your time,
Sebastian Celis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-14 10:13:01 CEST