You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Cohen <sc...@javactivity.org> on 2010/12/01 17:34:52 UTC

Unable to lock error: what is going on here?

$ svn update
svn: Unable to lock 'utscmd'

$ svn propget svn:ignore
utspkg_src
utscmd
utslib
utsbin
utstool

utscmd is a subdirectory of the current working directory.  It is 
included in svn:ignore.  Why is svn even trying to lock this directory?

The sequence of events here is that the project was checked out and then 
its build command run.  The build command created a number of 
directories, which have been added to svn:ignore so as not to figure in 
svn at all.

What am I failing to understand here?

Steve Cohen

Re: Unable to lock error: what is going on here?

Posted by Steve Cohen <sc...@javactivity.org>.
On 12/02/2010 05:24 PM, Bob Archer wrote:
>> On 12/02/2010 08:39 AM, Bob Archer wrote:
>>>> $ svn update
>>>> svn: Unable to lock 'utscmd'
>>>>
>>>> $ svn propget svn:ignore
>>>> utspkg_src
>>>> utscmd
>>>> utslib
>>>> utsbin
>>>> utstool
>>>>
>>>> utscmd is a subdirectory of the current working directory.  It
>> is
>>>> included in svn:ignore.  Why is svn even trying to lock this
>>>> directory?
>>>>
>>>> The sequence of events here is that the project was checked out
>> and
>>>> then
>>>> its build command run.  The build command created a number of
>>>> directories, which have been added to svn:ignore so as not to
>>>> figure in
>>>> svn at all.
>>>>
>>>> What am I failing to understand here?
>>>
>>> Are you sure utscmd is not already versioned. Ignores only works
>> on non-versioned files.
>>>
>>> BOb
>>>
>>>
>>>
>> Yes, that was the problem.  The directory was already versioned and
>> it
>> shouldn't have been.  The build process then came along and
>> destroyed it
>> (including its .svn subdirectory) and made a new one.
>>
>> However, I still don't understand why svn update is designed to
>> fail if
>> unversioned directories are found below it.  Couldn't they just be
>> ignored?
>
> try...
>
> svn up --force
>
> BOb
>
>
>
Thanks, Bob.

RE: Unable to lock error: what is going on here?

Posted by Bob Archer <Bo...@amsi.com>.
> On 12/02/2010 08:39 AM, Bob Archer wrote:
> >> $ svn update
> >> svn: Unable to lock 'utscmd'
> >>
> >> $ svn propget svn:ignore
> >> utspkg_src
> >> utscmd
> >> utslib
> >> utsbin
> >> utstool
> >>
> >> utscmd is a subdirectory of the current working directory.  It
> is
> >> included in svn:ignore.  Why is svn even trying to lock this
> >> directory?
> >>
> >> The sequence of events here is that the project was checked out
> and
> >> then
> >> its build command run.  The build command created a number of
> >> directories, which have been added to svn:ignore so as not to
> >> figure in
> >> svn at all.
> >>
> >> What am I failing to understand here?
> >
> > Are you sure utscmd is not already versioned. Ignores only works
> on non-versioned files.
> >
> > BOb
> >
> >
> >
> Yes, that was the problem.  The directory was already versioned and
> it
> shouldn't have been.  The build process then came along and
> destroyed it
> (including its .svn subdirectory) and made a new one.
> 
> However, I still don't understand why svn update is designed to
> fail if
> unversioned directories are found below it.  Couldn't they just be
> ignored?

try...

svn up --force

BOb

Re: Unable to lock error: what is going on here?

Posted by Steve Cohen <sc...@javactivity.org>.
On 12/02/2010 08:39 AM, Bob Archer wrote:
>> $ svn update
>> svn: Unable to lock 'utscmd'
>>
>> $ svn propget svn:ignore
>> utspkg_src
>> utscmd
>> utslib
>> utsbin
>> utstool
>>
>> utscmd is a subdirectory of the current working directory.  It is
>> included in svn:ignore.  Why is svn even trying to lock this
>> directory?
>>
>> The sequence of events here is that the project was checked out and
>> then
>> its build command run.  The build command created a number of
>> directories, which have been added to svn:ignore so as not to
>> figure in
>> svn at all.
>>
>> What am I failing to understand here?
>
> Are you sure utscmd is not already versioned. Ignores only works on non-versioned files.
>
> BOb
>
>
>
Yes, that was the problem.  The directory was already versioned and it 
shouldn't have been.  The build process then came along and destroyed it 
(including its .svn subdirectory) and made a new one.

However, I still don't understand why svn update is designed to fail if 
unversioned directories are found below it.  Couldn't they just be ignored?

RE: Unable to lock error: what is going on here?

Posted by Bob Archer <Bo...@amsi.com>.
> $ svn update
> svn: Unable to lock 'utscmd'
> 
> $ svn propget svn:ignore
> utspkg_src
> utscmd
> utslib
> utsbin
> utstool
> 
> utscmd is a subdirectory of the current working directory.  It is
> included in svn:ignore.  Why is svn even trying to lock this
> directory?
> 
> The sequence of events here is that the project was checked out and
> then
> its build command run.  The build command created a number of
> directories, which have been added to svn:ignore so as not to
> figure in
> svn at all.
> 
> What am I failing to understand here?

Are you sure utscmd is not already versioned. Ignores only works on non-versioned files.

BOb