> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Sent: donderdag 16 september 2010 19:47
> To: Greg Stein
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r997403 -
> 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
> > >
> > > - - ### A comment on 'revnum' says, "this could be NULL for non-
> > > - 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).
The rev value on not-present nodes is used during 'svn update' to determine if the not-present marker should be deleted at the end of the update during the revision bump. (It's value is never relevant in other places). If I remember correctly, if the revision is the same revision as the target of the update, the not-present node will be removed during directory close.
(We could probably use a hashtable for this garbage collection handling, instead of the revision. But we had the revision in svn_wc_entry_t.)
> 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.
I don't think they are really NULL, but that doesn't tell that the values are relevant.
Received on 2010-09-16 20:02:35 CEST