On Thu, Dec 12, 2002 at 10:04:24AM -0600, Karl Fogel wrote:
> Branko ÄŒibej <brane@xbc.nu> writes:
> > The unique IDs will someday be used as part of the NodeRevision primary
> > key -- that's necessary to support distributed repositories. Instead of
> > using a GUID explicitly, Bill suggests we hava (repository-specific)
> > mapping between GUIDs and RepositoryIDs. The RepositoryID namespace
> > would obviously be more compact, and therefore kinder to database
> > indexing routines. I suggested that the repo's own GUID would by
> > definition map to a Repository ID of 0.
>
> So instead of just using the GUIDs as the RepositoryIDs, we'd
> introduce another layer of indirection, in anticipation of db indexing
> performance problems due to the random bitstring nature of GUIDs?
>
> I almost think I'd rather have a more comprehensible schema with worse
> performance, than the other way around :-). At the very least, we
> should have some real data on the performance impact before
> introducing this layer of indirection.
>
> -Karl
Performance considerations aside, the table would not be
just another layer of indirection. Here's a proposed table:
Key: autoincremented id
Value: skelified version of an "svn_fs__info_t" structure, which
is defined something like:
/*** Repository Info ***/
typedef struct
{
/* a URL for this repository */
const char *url;
/* a friendly name for the repository */
const char *name;
/* short desc, used to describe the repository
in listings, etc. */
const char *short_desc;
/* long description of repository */
const char *long_desc;
/* the repository's UUID */
const char *uuid;
/* the repository's (encrypted) private key */
const char *privkey;
/* the repository's public key */
const char *pubkey;
} svn_fs__info_t;
--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 20:25:02 2002