[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re: bug with update/cleanup on win32

From: Phil <wildphil_at_wildmail.com>
Date: 2005-07-08 18:30:47 CEST

>> This is in the case that you try to svn update
>> a working copy in which one file is locked

> What do you mean by "locked"?

I mean, locked by the filesystem. On windows if
someone has a file open, attempts to open that
file for write just fail.

>> (not the first file that needs updating
>> though). svn errors (as it should) and
>> aborts the process. Any files already
>> updated remain updated, any later files
>> that aren't locked fail to be updated.

>> But that's not the worst of it. The directory
>> gets locked, but when you run svn cleanup it
>> complains that it can't apply the updates to
>> the files that have already been updated

>> (specifically, it complains about the lack of
>> file in .svn/tmp/filename).

> Can you give us a step-by-step recipe to
> reproduce, so we can see what you're
> describing firsthand?

Sure, on Windows do the following:
&#160; svnadmin create foo
&#160; svn co file://(path to foo)
&#160; cd foo
&#160; echo foo > foo
&#160; echo bar > bar
&#160; svn add foo
&#160; svn add bar
&#160; svn ci
&#160; echo foo >> foo
&#160; echo bar >> bar
&#160; svn ci
(ok, now you have foo and bar with 2 revisions)
&#160; svn update -r 1
(ok, your working copy is on revision 1)
&#160; svn update
(ok, both files get changed back to r2)

now run in 1 window:
&#160; perl -e "open I, '<bar'; sleep 200; close I"
this locks the bar file. You can't rename it,
open it for writing, etc. There are many ways to
achieve this but this is the easiest one.

In the other window:
&#160; svn update -r 1
You should now get an error when trying to update
bar. You working copy is now locked. Kill off the
perl and try to recover it...

Note that I've reproduced this behaviour with
windows SVN, TortoiseSVN, and linux SVN on to a
samba share.

I know that filing this as a P1 bug without
discussion was a little hasty :), but basically
this behaviour is stopping us replacing CVS with
SVN. In one situation, we have a module of lots
of perl tools, and we have a live checkout of
this on the group's path. If you were to try to
update the tools and someone happens to be
running one of them it will be locked, and we'll
end up shafted :(


The following message is not under the author's control:
Help Make Poverty History – Sign the ONE Declaration: 
http://www.Care2.com  Free e-mail. 100MB storage.  Helps charities.
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 8 18:30:47 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.