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.
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
>>>>$ svn add ?
>>>>svn: warning: '2' is already under version control
>>>>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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Aug 3 01:34:43 2005