> 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.
> > . 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.
> >...
> > In fact all corrections/improvements to the data model are greatly
> > appreciated.
>
> * the nodes need properties :-)
Yeah, their representation is modeled, but the fact that nodes have a
derived property list based on the representation isn't. I'll add that.
Oh, I see what happened, the automagic ER generation process stuck this
in the wrong table. How lame. *Adjusts the conceptual constraints*
> * 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. 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.
> * why does "String" have a rep ID?
It doesn't. The (ID) in parenthesis indicates that the object in
question has a primary key of the object's id. Strings and
Representations have separate IDs. (I'm talking about the conceptual
model here, the ER diagram is so not even close to being usable atm.)
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.
> * 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.
Thanks,
Bill
---------------------------------------------------------------------
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