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

Re: Re: Initial SVN Repository data model

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-02-26 21:52:22 CET

On Tue, Feb 26, 2002 at 12:09:29PM -0800, Bill Tutt wrote:
>
> > From: Greg Stein [mailto:gstein@lyra.org]
> >
> > On Tue, Feb 26, 2002 at 01:31:38AM -0800, Bill Tutt wrote:
> > > I've managed to put together a SVN data model that mostly represents
> > > what we currently have.
> > >
> > > . Directories are always modeled as being stored inline
> >
> > What do you mean "inline" ? As in "the entries are not compressed" ?
>
> Yes. Sorry, they're modeled explicitly, and not as full text
> representations as they are currently used in SVN. I could change that
> so that the DirectoryEntries are derived from the representation. I
> should probably do that so we have an accurate initial SVN model.

Hmm. Well, if you want a "current model" rather than "Right model", then go
for it. But I think the Right model is to keep directories separate -- the
entries list does not go into the rep.

> > > . Do we use the REP-OFFSET portion of the delta window?
> >
> > Yes, we use both the offset and size of the window.
>
> Ok, I'll add it to the model.

Um (did more checking). We don't use REP-OFFSET. We use the OFFSET
associated with a WINDOW (in the DELTA element). The REP-KEY is not
optional, as shown in the structure.

So... each window *does* have an offset/size (as you already had in the
model).

>...
> > * I don't understand the "CopyNode" field in the ER diagram; looking at
> > the
> > model, it seems "IsCopyNode" is the problem. That is really "if kind ==
> > copynode". IOW, the table just needs "kind"
>
> This is straight from the current SVN filesystem structure. Copy is
> currently treated separately from Kind.

Ah, that's right.

> CopyNode is a bool, the node is
> either a copy node or it isn't. Remember this is a model of the current
> SVN filesystem and NodeRevisions that are copy nodes don't share the
> same representation atm.

I think it might be kind of a lose to try and model the current FS. Your
diagram would have to show the entries in the rep, the plists, etc.

>...
> Ah, you were looking at the ER diagram. The reason that it's there atm
> is because the ER diagram was automagically generated from the
> conceptual diagram. The automagic generation process got confused about
> how it was going to translate the subtype relationship into a physical
> table.

Okay.

> > * I'd like to see prop names normalized into another table (there will be
> > a
> > lot of duplication there)
> > * speaking on props, we have some standard props, which we may want to
> > model
> > explicitly as columns: created-rev, log msg, author, date
>
> Noted. Physical schema tweaking and conceptual model changes will want
> to happen after we've validated the conceptual model against what SVN
> currently does.

Okay, but in my Right Model, I would see those as explicit items in the
storage. Although, it could also be said that you could have a "cleaner"
*model* with them as normal props (i.e. the FS is purely a versioning store
and doesn't care about the props). Only when you go to build a system do you
pull them out.

[ although created-rev is actually maintained/managed by the FS ]

Cheers,
-g

-- 
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 Oct 21 14:37:10 2006

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.