sussman@tigris.org wrote:
>Author: sussman
>Date: Tue Nov 16 19:07:33 2004
>New Revision: 11930
>
>
>+/* Helper func: create a new svn_lock_t, everything allocated in pool. */
>+static svn_error_t *
>+generate_new_lock (svn_lock_t **lock_p,
>+ const char *path,
>+ const char *owner,
>+ long int timeout,
>+ apr_pool_t *pool)
>+{
>+ apr_uuid_t uuid;
>+ char *uuid_str = apr_pcalloc (pool, APR_UUID_FORMATTED_LENGTH + 1);
>+ svn_lock_t *lock = apr_pcalloc (pool, sizeof(*lock));
>+
>+ lock->path = apr_pstrdup (pool, path);
>+
>+ lock->owner = apr_pstrdup (pool, owner);
>+
>+ apr_uuid_get (&uuid);
>+ apr_uuid_format (uuid_str, &uuid);
>+ lock->token = uuid_str;
>
>
Hm. I wonder if we really do have to generate a UUID for each lock
token. Does the DAV spec require a UUID, or just any globally unique
string? It strikes me that we'll use up a fair amount of randomness when
we could easily just take the repositury UUID and concatenate a sequence
number. Just thinking out loud here...I wouldn't think generating UUIDs
for locks would eat up all available random bits.
>+ lock->creation_date = apr_time_now();
>+
>+ if (timeout)
>+ {
>+ long int seconds;
>+
>+ seconds = apr_time_sec(lock->creation_date);
>+ seconds += timeout;
>
>
Pleas use an apr_time_t here instead of a long... seconds_from_epoch
rolls over fairly soon, and we don't want another Y2K thingie.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 21 03:52:54 2004