> From: Branko Cibej [mailto:brane@xbc.nu]
>
> 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.
>
Although if mbk decides to grace us with a new BDB table and new ra
vtable methods to achieve our goal of a GUID, far be it from us to
dissuade him down this wonderful route. :) A new table certainly saves
us even more mess in the property handling code.
Bill
---------------------------------------------------------------------
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:07:27 2002