On Wed, 2010-09-15 at 16:17 -0400, Greg Stein wrote:
> On Wed, Sep 15, 2010 at 13:19, <julianfoad_at_apache.org> wrote:
> >...
> > - - ### A comment on 'repos_id' and 'repos_relpath' says they may be null;
> > - is this true and wanted?
>
> Yes. That meant "use the parent's information, and extend it to
> compute this node's value".
>
> > + - The Node-Rev group points to the corresponding repository node-rev.
> >
> > - - ### A comment on 'revnum' says, "this could be NULL for non-present
> > - nodes -- no info"; is this true and wanted?
> > + - If not used (as specified by the 'presence' table above), the values
> > + are undefined.
> > + ### Perhaps we should set them to null to make it clearer.
>
> Yes, we should.
OK, I'm trying this - enforcing repos_id/relpath/rev being null for
not-present nodes).
I'm concerned about 'file externals':
svn_wc__db_temp_op_set_file_external() creates a row with status
'not-present' and claims that it is 'switched', and inserts a repos-id
and repos_relpath.
I'm not yet clear on what this really means. Sure it's a 'hack' but I
guess this is the way we do it for the time being, so, the statement
that not-present implies repos-id/relpath/revnum are all null is false.
Ignoring that for a moment, I'll start with splitting
svn_wc__db_base_add_absent_node() into two functions: itself for absent
and excluded, and new function '..._add_not_present_node()' for
'not-present'. In the current code it is handling all three cases, and
treats them all identically. Splitting the cases up is more sensible.
- Julian
> > Content columns: (kind, properties, depth, target, checksum)
> > ---- ---------- ----- ------ --------
> > @@ -165,6 +177,7 @@ Overview of BASE_NODE columns:
> > - Includes a copy of the corresponding date and author rev-props.
> >
> > - If not used (as specified by the 'presence' table above), all null.
> > + ### Not checked; in practice these columns may have undefined values.
>
> They should never be undefined. They should be null.
>
> We should never have undefined information in our schema. That leads
> to madness...
>
> Cheers,
> -g
Received on 2010-09-16 19:47:31 CEST