[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-05-27 18:40:37 CEST

"Brian W. Fitzpatrick" <fitz@red-bean.com> writes:

> I think it's all about intent. Given 'wc/a' and 'wc/b', if you
> already have a lock on wc/a and then run 'svn lock wc/a wc/b', you've
> already got a lock on wc/a, so why error? We just inform you that
> you already had a lock, then move on to wc/b.

I don't have already have the lock, the lock belongs to somebody else.
Before locking I checked the repository and 'wc/a' was an unlocked
file, but I was beaten to the lock. 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.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 27 18:41:37 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.