On Dec 9, 2004, at 2:45 PM, Peter N. Lundblad wrote:
>>
>> + * If @a current_rev is a valid revnum, then do an out-of-dateness
>> + * check. If the revnum is less than the last-changed-revision of @a
>> + * path, return SVN_ERR_FS_OUT_OF_DATE.
>> + *
>
> As I understand the spec, a client can add a file and lock it, to
> "reserve" the pathname. Then, the server needs to do out-of-dateness
> checking meaning that the file shouldn't be in HEAD. What do I pass in
> this case? Maybe it is celar from the code, but the docstring doesn't
> say
> what happens to a non-existent file.
>
I'm not exactly sure what you're asking, but I think it's this question:
"What happens if the caller of svn_fs_lock() passes in a
'current_revnum' that represents the working-version of the file being
locked, but then the fs discovers that the path doesn't exist in HEAD?"
I think the correct answer is: svn_fs_lock() should return
SVN_ERR_FS_OUT_OF_DATE. It means that somebody's trying to lock
something in their working copy, but somebody else has already deleted
the thing in HEAD. That definitely qualifies as "out of date". In
fact, I already accounted for this in the libsvn_fs_base code. I'll
update the docstrings in svn_ra.h and svn_fs.h to mention this.
I think there's another question you might be asking also:
"What happens if a user *deliberately* runs 'svn lock' on a
non-existent wc-path? What should we pass for the current_revnum
argument?"
My answer to this is: I don't think the svn client should be in the
business of reserving non-existent paths. Generic DAV clients do it
occasionally, so svn_fs_lock() needs the functionality. But I think we
should just remove that concept from the svn client. I'll twiddle
svn_ra.h there as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 10 03:57:35 2004