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

Re: Can't Cleanup...

From: Jason Ulrich <julrich_at_micds.org>
Date: 2006-10-04 14:13:47 CEST

I'm an idiot! Everything on our install of svn has to be done under root.
 Even though I'm convinced that there were problems with some of the
directories, running svn cleanup as root cleared it up. Sorry to bother
everybody.

JU

Duncan Murdoch <murdoch@stats.uwo.ca> on Tuesday, October 03, 2006 at 2:45
PM -0600 wrote:
>On 10/3/2006 3:28 PM, Ryan Schmidt wrote:
>> On Oct 2, 2006, at 14:37, Jason Ulrich wrote:
>>
>>> I've tried to run svn cleanup on several levels of my working
>>> copies and I
>>> continually run into locks. I think somebody who hadn't used
>>> subversion
>>> before tried to delete the .svn directories on a couple directories
>>> and
>>> now we're not able to do anything.
>>>
>>> Svn status shows the files as "M" and not "L". Yet, the errors keep
>>> saying that they are locked.
>>
>> I think you're mixing up two unrelated uses of the word "lock" when
>> relating to Subversion.
>>
>> One sense, which I think applies to your situation, is that
>> Subversion had trouble dealing with your working copy, and left some
>> tokens around, which svn cleanup is meant to clean up, except if you
>> removed .svn directories then it won't be able to, so your working
>> copy will still be locked, in that sense.
>>
>> The other sense, the one which has an L status, is when you want to
>> be the only person able to work on a given file, and you lock it in
>> the repository until you're done with your changes. I don't think
>> this applies to you.
>
>This isn't actually correct. I interrupted an "svn switch" this
>afternoon (because I realized that I needed a "make clean" first), and
>it left "svn status" listing a number of files labelled with "L". "svn
>cleanup" managed to clean things up properly. (This was with the svn
>1.3.2 client.)
>
>Duncan murdoch
>
>
>>
>> But, if you post the exact error message you get, that might clarify
>> which of these cases applies.
>>
>>
>>> What's our best plan of attack here?
>>
>> Best bet is to check out a new working copy, manually move over any
>> uncommitted changes you still had in the old working copy, and in the
>> future, don't remove .svn directories or anything in them. That's
>> Subversion's domain and it needs everything there to be under its
>> control so it knows what's up.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 4 14:14:48 2006

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.