On Wed, Dec 11, 2002 at 05:38:32PM -0800, 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.
>
> FYI,
> Bill
So, I think there are two decisions:
1.) where to put it.
a.) a distinguished file
b.) a distinguished revision property
c.) an fs table
2.) how to get it.
a.) new ra function
b.) through existing ra revision props interface
(1a + 2a) is simple and easy to implement, and strikes me
as unlikely to break anything.
(1a + 2b) will require hacking up the rev-prop codepath
to catch access to svn:uuid on rev 0 and redirect
access to the file.
(1b + 2a) requires extending the ra vtable, which will touch
a lot of things, just to implement a read-only
property. Of all the combinations, this one strikes
me as the least attractive.
(1b + 2b) will require hacking up the rev-propset codepath
to deny writes to svn:uuid on rev 0. This is probably
the "least code required" option.
(1c + 2a)
(1c + 2b) These are roughly equivalent to those with 1a, with
the following exceptions:
1.) it will be more work
2.) this work is good work, in that moves us
towards a data model that will support
distributed repositories.
My personal leaning is towards (1c + 2a).
--ben
---------------------------------------------------------------------
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:08:21 2002