Ben Collins-Sussman <sussman@collab.net> writes:
> Mike is wanting some kind of universal struct like this:
>
> typedef struct svn_prop_t
> {
> const char *name,
> svn_stringbuf_t *value,
> enum prop_kind kind;
> }
>
> The idea here is that these are the objects that the client deals
> with; when travelling over the wire, we have functions that 'parse'
> and 'unparse' the names by adding or removing proper prefixes.
> (Actually, more than that: some DAV: props map to totally different
> names in the working copy. Our parse/unparse routines would cover
> those too.)
Is there a big advantage of having a new struct with a `kind' field?
In many cases, we don't want to strip off the prefix, we merely want
to answer the question "What kind of prop is this?". Once we know the
answer, we're going to use the whole property name in whatever we do
next (or, in the case of entry props, we use a completely different
name anyway). So, I was thinking of an interface along these lines:
/* Subversion distinguishes among several kinds of properties.
* There is no "unknown" kind; if there's nothing special about a
* property name, the default category is `svn_prop_regular_kind'.
*/
enum svn_prop_kind
{
svn_prop_entry_kind, /* In .svn/entries, i.e., author, date, etc. */
svn_prop_wc_kind, /* Client-side only, often stored by ra layer. */
svn_prop_regular_kind /* Seen if user does "svn proplist"; note
that this includes some "svn:" props and
all user props. */
};
/* Return the prop kind of a property named NAME, and set
* *PREFIX_LEN to the length of the prefix of NAME that was
* sufficient to distinguish its kind.
*/
enum svn_prop_kind svn_property_kind (int *prefix_len,
const char *prop_name);
Mike, sitting next to me and reading this over my shoulder, registers
approval.
Other comments?
-K
---------------------------------------------------------------------
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:05 2006