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

Re: Re: Minimizing the `revisions' table.

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-06-15 03:05:36 CEST

On Fri, Jun 14, 2002 at 01:55:27PM -0700, Bill Tutt wrote:
> > From: Greg Stein [mailto:gstein@lyra.org]
> >
> > On Fri, Jun 14, 2002 at 01:10:11PM -0700, Bill Tutt wrote:
> > > > From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> > >...
> > > > Oh, "replace = delete + add", where modify means "text or prop
> > > > changes". Sorry for the ambiguitiy.
> > >
> > > Replace is unnecessary if the primary key of the table is:
> > > (TxnID, NodeRevisionID)
> >
> > BDB doesn't do multi-column primary keys. Well, it *can*, but you could
> > not come along later and ask for all rows related to TxnID.
> Duplicate keys + TxnID as the BDB key would work as well.
> I mean we're only either inserting one row or returning all the rows
> anyway right?

Sigh. Do I need to hit you with a Cluestick? :-)

The original proposal was keyed by TxnID, with duplicate keys. The problem
that started the discussion about alternate keying proposals was to be able
to collapse changes, so how do you quickly find previous changes? But now
you bring us right back to the original...


The original proposal is fine with me, but the "type" of change won't really
work. Any change is going to be some kind of add or delete. It could
probably detect certain kinds of "replace" -- where you simply overwrite a
directory entry rather than deleting it first, but those might just be
called "modify". Whatever...


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 15 03:04:40 2002

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