so i finally figured out what was wrong. i wasnt quite at the root - there was
one more directory up (where trunk & tags dirs were) and thats where the lock
was that was killing my commit. So i removed that stray lock and i was fine.
But it seems to me that svn cleanup in the directory where svn commit was
failing should clean up that lock shouldnt it? It seems funny that svn tells you
to do a cleanup and then doesnt actually cleanup the lock that needs cleaning in
the above dir. Im on svn version 1.3.1 so maybe this issue got worked out in
later versions?
Thanks for your help - i was about to do a new checkout when i finally looked at
the above dir and saw the lock.
Mark
Thomas Harold wrote:
> Erik Huelsmann wrote:
>> On 11/8/06, Mark Gibson <mgibson@fruitfly.org> wrote:
>>> i had a svn commit just hang - ctrl-C wouldnt end it. so i killed the
>>> svn
>>> process. now when i commit i get:
>>>
>>> svn commit
>>> svn: Working copy '/home/mgibson/pheno-tool/java/svn/phenote' locked
>>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
>>> details)
>>>
>>> i svn cleanup as it suggests but still get same message.
>>
>> Then probably the working copy wasn't cleaned up successfully. Which
>> svn version are you using? What error does 'svn cleanup' generate?
>
> This sounds similar to the bug that I pointed out about 1-2 weeks ago,
> where killing the SVN process through external means (not using Ctrl-C
> but hard killing the process in task manager) will always leave the
> local working copy in a "broken" state.
>
> A lot of times, the only fix that I've found is to move your "good" copy
> out of the way, remove all .svn/_svn folders from the "good" copy. Then
> bring down the latest version that is in the repository and paste your
> "good" copy files over top of the newly downloaded working copy.
>
> -----------------------------------------
>
> (The old bug report from 2 weeks ago)
>
> 1) have a folder with 100+ files in it (the more the merrier, it can
> happen with only a single file, it's just easier to test with 100+ files)
>
> 2) start an 'svn up' operation that is pulling down files
>
> 3) kill the "svn.exe" process in Task Manager (not Ctrl-Break or Ctrl-C,
> which SVN handles gracefully, it has to be a hard kill)
>
> 4) try the 'svn up', SVN will (properly) complain about locks and tell
> you to run "svn cleanup" (good so far).
>
> 5) run svn cleanup
>
> 6) try "svn up" again, svn will now complain:
>
> svn: Failed to add file 'ex030626.log': object of the same name already
> exists
>
> So there's 2 parts to the bug, or I don't know where the bug lies:
>
> a) "svn up" is liable to leave the working copy in an unfixable state if
> it dies unexpectedly
>
> b) "svn cleanup" isn't doing its job of cleaning up the working folder
> and matching things back up.
>
> -------------------------------------
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 9 18:52:06 2006