[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-12-09 22:29:47 CET

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

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

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.