On Nov 4, 2004, at 3:20 PM, Peter N. Lundblad wrote:
>
> I think you are consistent in adding periods to the new messages. :-)
I will fix, thanks.
> ...
>> +/** Set @a *user to the current @a fs user. */
>> +svn_error_t *svn_fs_get_user (svn_fs_user_t **user,
>> + svn_fs_t *fs);
>
> I assume it sets *user to NULL if there is no current user. Might want
> to
> add that.
Will fix.
>
>> +/** Lock @a path in @a fs, and set @a *token to a lock-token
>> + * representing the new lock, allocated in @a pool.
>> + *
>> + * @a fs must have a user associated with it, else return @c
>> + * SVN_ERR_FS_NO_USER. Set the 'owner' field in @a *token to the
>> + * username of the current @a fs user.
>> + *
>> + * If path is already locked by a different user, then return @c
>> + * SVN_ERR_FS_PATH_LOCKED. If @a force is true, then delete the lock
>> + * on path (if any), and unconditionally create a new lock.
>> + *
>> + * If @a timeout is zero, then create a non-expiring lock. Else, the
>> + * lock will expire in @a timeout seconds after creation.
>> + *
> Why not have an absolute time instead? There may be some time between
> the
> client starting the request and this function actually getting called.
> Wasn't some DAV client using 2 minute locks? Might not be very
> important.
> I jsut don't see a reason to have a relative time.
The only thing that will ever use the expiration feature is a generic
DAV client. The HTTP LOCK request asks for expiration this way: in
"seconds-from-now". So we were just trying to make the fs API match,
for ease of use.
>
>> +typedef struct svn_lock_token_t
>> +{
>> + const char *path; /* the path this token applies to */
>> + const char *uuid; /* unique lock token identifier */
>> + const char *owner; /* the username which 'owns' the
>> lock */
>> + apr_time_t creation_date; /* when lock was made */
>> + apr_time_t expiration_date; /* (optional) when lock will expire;
>> + A value of 0 will never expire. */
>> +} svn_lock_token_t;
>
> Is it the value that expires? :-)
>
Ha ha, will fix. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 4 23:34:30 2004