[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: repository GUIDs

From: mark benedetto king <bking_at_answerfriend.com>
Date: 2002-12-12 02:58:54 CET

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).


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

This is an archived mail posted to the Subversion Dev mailing list.