[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-05-27 22:13:06 CEST

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 Fri May 27 22:03:42 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.