[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 20:15:42 CET

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.