I am currently in the middle of a migration from VSS to subversion. As
part of this migration I am maintaining both a VSS database and a
Subversion repository for a short while.
VSS is configured with the default behavior of keeping files in the
working copy read only until they are checked out (sort of like
locking, but locking isn't required).
I had a case today where I went to commit my changes to Subversion, and
I got a message that my working copy was not up to date. So I issued a
'svn up' command with the intention of trying my commit again. At this
point things went horribly wrong because the update was unable to deal
with the read-ony files that it was trying to replace. The update
aborted part-way through. As part of the update one of my files needed
to merge, since I was making changes to it it was not read-only.
I changed all of the files to read-write and tried the update again.
There was an error message that the working copy was locked and I was
told that I needed to do a 'svn cleanup'. This is were everything went
to hell. :) (I recovered eventually , so I'm still able to use a
smilie at this point... it wasn't fun at the time though)
The svn cleanup command would not complete. The working copy was stuck
in a locked state. I could not properly update or commit.... So then
I decided to be brave and poke around in the ".svn" folder to see if I
could make it go. Sort of like wacking a piece of high-tech equipment
on the side when it acts up - sometimes it works, sometimes you just
break it more :)
I broke it more.
Every time I tried to update many temp files where created with a root
name the same as the file that required the merge. Something was stuck
on this... I deleted the lock file... and some log files (probably a
bad move) but there was stuff missing from .svn/tmp/.... that
prevented the update from working (a missing .svn-base file for the
file that required the merge) ... Stupidly I created such a file just
to get things going (nothing else was working), but I didn't give the
file proper content - so when I 'updated' my file was marked as
conflicted and it was full of bogus changes.
I eventually cleaned it up by getting the proper latest revision with
'svn cat' to replace the main svn-base file, manually merging my
changes with it and resolving the conflict... but it was scary.
My point in all this is that Subversion didn't handle the read-only
file very well at all. Following the instructions in the messages from
Subversion did not unlock my workspace. The suggested "cleanup" was
useless. The error was simple enough and it probably can be handled
smoothly with a little tweaking.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 7 06:38:40 2004