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

Re: svn commit: r14842 - trunk/subversion/clients/cmdline

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-08-03 01:33:42 CEST

Ping! Did this bug ever get fixed? I think the bug being discussed is that
when "svn lock" fails because somebody else already has the lock, it was only
giving a warning but should be giving an error.

- Julian

Peter N. Lundblad wrote:
> On Fri, 27 May 2005, Brian W. Fitzpatrick wrote:
>
>>On May 27, 2005, at 11:40 AM, Philip Martin wrote:
>>
>>> I also checked 'wc/b' and it too
>>>was an unlocked file, in that case somebody beat me and deleted it.
>>>
>>>> It's the same thing
>>>>with attempting to 'svn add' a file that's already been added:
>>>>
>>>>$ touch 1 2 3
>>>>$ svn add 2
>>>>A 2
>>>>$ svn add ?
>>>>A 1
>>>>svn: warning: '2' is already under version control
>>>>A 3
>>>>
>>>>In your case, however, wc/x has been replaced with a directory and I
>>>>consider that to be a different case--you can't just lock the
>>>>directory, and you don't already have a lock on it.
>>>>
>>>>Does that make sense? Am I misunderstanding what you're saying?
>>>
>>>No, it doesn't really make sense. It seems to be arbitrary whether a
>>>particular failure is treated as non-fatal. I suppose we do have
>>>other arbitrary behaviour, whether unversioned files are skipped or
>>>not, but it still strikes me as strange.
>>
>>Well, I think you're right--this is a bug. I think that it's OK to
>>warn on 'svn lock' if we already have the lock in our working copy,
>>but if someone else has the lock, I think an error is in order.
>
> Seems reasonable to me. So this is a bug, but not in the notifier:-) It
> can't do anything about it because it has a void return value. So it is
> probably the svn_client_lock/unlcok that need to decide which errors are
> to be treated as warnings and pass them to the notifier.
>
> Regards,
> //Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 3 01:34:43 2005

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

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