Bill Tutt wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Yes. Changing a unique ID is always a bad idea. Ben, d'you think you
>>
>>
>can
>
>
>>make that one property read-only? I'm afraid it probably means adding
>>
>>
>a
>
>
>>rudimentary access-control mechanism for revision props.
>>
>>
>
>While Brane makes a great comment about ACLs and revision properties,
>I'd like to point out at the filesystem level that the best place to
>stick this information is in a new BDB table. Even if you expose the new
>table through the ra layers as a revision property, we're still further
>ahead of the game if we add a new BDB table for this.
>
>The new table is very simple. All it needs at the moment are two
>columns:
>RespositoryID and GUID. RepositoryID is just another one of our fun
>monotonically increasing ID fields, and the GUID column is the
>repository GUID. The reason for structuring the data this way is that
>eventually we'll want to widen at least the NodeRevision primary key by
>RepositoryID. We don't want to widen the NodeRevision PK by the
>repository GUID mainly because GUIDs cluster so poorly on indices. No
>need to waste valuable page &/or index space.
>
>
I find myself agreeing with Bill yet again. :-)
But perhaps we can work out a compromise: _this_ repository's GUID is a
special case, and we can always map it (later) to RepositoyID 0. Which
means that we don't actually need a new BDB table at this very moment --
since we won't be widening the NodeRevision PK now -- but we _do_ need a
way to store the GUID and read it.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 12 03:01:29 2002