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