kfogel@collab.net writes:
> Branko Čibej <brane@xbc.nu> writes:
> > 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.
>
> I was favoring your way too, because then one could look at a lock
> token and know which repository it was associated with. Like if the
> format were
>
> REPOS_UUID:LOCK_UID
>
> where LOCK_UID is just a constantly incrementing number unique within
> that repository..
I can attest to Karl's favoring of that idea (we had this conversation
in the office the other day). My only concern was related to
transportability of locks. *If* we extend our dumpfile format and
backing code to handle lock transport, then we want our lock tokens to
be backend-inspecific. So, my requirements for our tokens are that
they use a consistent format across all the backends (either by
sharing the id-generating code or by simply agreeing to a format, such
as the above) and that they not be tied to the likes of an
auto-incrementing primary key in a particular implementation (since at
load-time we'd have to ensure that we got those same indexes again).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 22 19:19:34 2004