[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 17:51:32 CEST

"Brian W. Fitzpatrick" <fitz@collab.net> writes:

> On May 26, 2005, at 3:52 PM, Philip Martin wrote:
>> Also I'm not really clear what constitutes a "non-fatal locking
>> error":
>> $ svn lock wc/a wc/x
>> svn: warning: Path '/a' is already locked by user 'pm' in
>> filesystem '/home/pm/sw/subversion/obj/repo/db'
>> ../svn/subversion/libsvn_fs_fs/err.c:286: (apr_err=160017)
>> svn: '/x' is not a file in filesystem '/home/pm/sw/subversion/obj/
>> repo/db'
>> One of those comes out as a warning and the other as an error, but I
>> see no reason why they should be different. I can't ensure that wc/x
>> is a file before making the call any more than I can ensure that wc/a
>> is unlocked.
> Sure, but you're attempting to lock a file here, not to 'svn add' a
> file and then lock it. Finding an existing lock ("This file is
> already locked") is quite different than attempting to lock a non-
> existent or non-versioned file ("Lock wc/x? I see no wc/x here.").

I don't really understand why they are "quite different".

Both wc/a and wc/x are files in my working copy, neither is locked.
If I do a check (status or ls) before issuing the lock command I see
two unlocked files. There's a window between my check and lock
command during which somebody locks one file and replaces the other
with a directory, so both lock attempts fail.

It's not clear to me why we have chosen to make one of those
"non-fatal". The best I can come up with is that "already locked"
occurs more often. Is that really it? If an error occurs frequently
we make it non-fatal?

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:00:07 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.