On Mon, Mar 1, 2010 at 07:23, Julian Foad <julian.foad_at_wandisco.com> wrote:
> For review, please. The patch below aims to provide complete doc
> strings for (the existing implementation of) the WC-NG properties API.
Looks great, thanks.
> I assume "properties" refers to regular, versioned properties
> I checked the implementation with regard to returning an error when the
> node is not found.
It should always return an error. We were very inconsistent before,
and my intent was to error in all cases when a node is not found
(thus, my slight concern around the read_kind() function).
If it doesn't error, then that should be considered a bug.
> I believe svn_wc__db_base_get_props() is meant to return an empty
> (non-NULL) hash to represent "no properties", both because that's
> consistent with the input and outputs of the rest of these functions and
> because the rest of these functions never write "null" to the
> "properties" column of the BASE table when writing an empty set of
> properties. The non-nullness of that SQL column is not (yet) documented
> so I am not certain that there are no other functions that could write
A null value in ACTUAL_NODE.properties means "no changes w.r.t the
pristine properties". Any value in there is the complete set of
I don't think that a null value in WORKING_NODE or BASE_NODE makes
sense. We could interpret that as "incomplete", or as a short-form for
"no properties". iirc, a skel for empty-property-hash is "()" (ie.
just 2 bytes).
My belief is that nodes "shouldn't" have incomplete data. That we
should create a node when we have all of its data. wc-1 and Editor v1
don't behave that way, however, so we're kind of stuck until we can
get much further into rewriting those processes. This is also why I
want to see all of a directory's child names at directory creation
time -- you then know everything about the directory (though each
child is incomplete because it is just a name).
Received on 2010-03-02 00:18:38 CET