On May 27, 2005, at 10:51 AM, Philip Martin wrote:
> "Brian W. Fitzpatrick" <firstname.lastname@example.org> writes:
>> On May 26, 2005, at 3:52 PM, Philip Martin wrote:
>>> Also I'm not really clear what constitutes a "non-fatal locking
>>> $ 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/
>>> 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
>>> is a file before making the call any more than I can ensure that
>>> 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?
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. 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?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri May 27 18:08:09 2005