Re: svn commit: r12264 - in branches/locking/subversion: include libsvn_client libsvn_fs libsvn_fs_base libsvn_fs_fs libsvn_ra_dav libsvn_ra_local libsvn_ra_svn libsvn_repos mod_dav_svn svnadmin svnserve

["Peter N. Lundblad" <pe...@famlundblad.se>]

On Thu, 9 Dec 2004 sussman@tigris.org wrote:

> Author: sussman
> Date: Thu Dec  9 14:00:28 2004
> New Revision: 12264
>
> Modified: branches/locking/subversion/include/svn_fs.h
> Url: http://svn.collab.net/viewcvs/svn/branches/locking/subversion/include/svn_fs.h?view=diff&rev=12264&p1=branches/locking/subversion/include/svn_fs.h&r1=12263&p2=branches/locking/subversion/include/svn_fs.h&r2=12264
> ==============================================================================
> --- branches/locking/subversion/include/svn_fs.h	(original)
> +++ branches/locking/subversion/include/svn_fs.h	Thu Dec  9 14:00:28 2004
> @@ -1498,6 +1498,10 @@
>   * If @a timeout is zero, then create a non-expiring lock.  Else, the
>   * lock will expire in @a timeout seconds after creation.
>   *
> + * 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.

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r12264 - in branches/locking/subversion: include libsvn_client libsvn_fs libsvn_fs_base libsvn_fs_fs libsvn_ra_dav libsvn_ra_local libsvn_ra_svn libsvn_repos mod_dav_svn svnadmin svnserve

[Ben Collins-Sussman <su...@collab.net>]

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