On Mon, Mar 1, 2010 at 07:23, Julian Foad <[email protected]> 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 > throughout. Yes. > 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 Correct. > 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 > "null". 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 (changed/deleted/added) properties. 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). >... Cheers, -g
