I second this post. I too have done this. Same circumstances as well,
using both VSS and SVN at the same time (for a short while). It does
seem like subversion could handle such a simple scenario (read-only
files) a bit more gracefully. I was more fortunate, in that I had my
changes committed to VSS already, so I just blew away my subversion
working copy and did a fresh checkout to fix the problem (again, svn
cleanup was of no use).
Scott Palmer wrote:
> 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
--
*Greg Goodrich*
Development Manager
*MediNotes Corporation*
1025 Ashworth Road, Suite 222
West Des Moines, IA 50265
Phone: 515.327.8850 ext. 251/
/Fax: 515.327.8856
<http://www.medinotes.com>
*Charting Plus - "The Best EMR Value on the Market!"
**www.medinotes.com* <http://www.medinotes.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 7 21:26:04 2004