You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Scott Palmer <sc...@2connected.org> on 2004/10/07 04:38:19 UTC
Bad handling when read-only files are encountered
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
Re: Bad handling when read-only files are encountered
Posted by Greg Goodrich <gg...@medinotes.com>.
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
Re: Bad handling when read-only files are encountered
Posted by Scott Palmer <sc...@2connected.org>.
On Oct 7, 2004, at 3:57 PM, Nathan Kidd wrote:
> Scott Palmer wrote:
> <SNIP>
>> 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.
> <SNIP>
>> 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.
>
> I also had this experience a few weeks ago, when copying files from a
> VSS working copy to my svn working copy and trying to commit. It
> failed in the same way. I went down the same path as you (remove
> read-only, try svn cleanup, poke around in .svn).
>
...
> The svn code should check if a file is read-only before attempting
> whatever it has to do for the commit, rather than plowing ahead,
> failing, and essentially breaking your WC.
On Oct 7, 2004, at 3:25 PM, Greg Goodrich wrote:
> I second this post. I too have done this. ... svn cleanup was of no
> use).
Well I was hoping one of the Subversion developers might have a
comment, but nothing so far. Should a bug report be filed on this?
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bad handling when read-only files are encountered
Posted by Nathan Kidd <na...@hummingbird.com>.
Scott Palmer wrote:
<SNIP>
> 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.
<SNIP>
> 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.
I also had this experience a few weeks ago, when copying files from a
VSS working copy to my svn working copy and trying to commit. It failed
in the same way. I went down the same path as you (remove read-only, try
svn cleanup, poke around in .svn).
I finally got around the problem by doing a checkout of the same svn
tree in a separate location and then used that fresh .svn directory to
replace the corrupted one. This presumably looses any special meta info
about a mixed revision WC, scheduled adds/deletes, etc., but in my case
all I had to do was re-add the new files I'd copied into the WC and it's
been working fine ever since. A hack, but it beats the merge/conflict
gymnastics you described.
The svn code should check if a file is read-only before attempting
whatever it has to do for the commit, rather than plowing ahead,
failing, and essentially breaking your WC.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org