[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn propedit URL

From: David Glasser <glasser_at_mit.edu>
Date: 2006-09-30 16:41:34 CEST

On 9/29/06, David Glasser <glasser@mit.edu> wrote:
> There's also some validation and canonicalization in svn_wc_prop_set2
> that need to be factored out into libsvn_subr or something. Some of
> this is easy (don't set svn:ignore on files, strip whitespace around
> svn:keywords). Some of it... less so: there's a check that a
> svn:eol-style is reasonable, and a full-blown attempt to parse
> svn:externals with svn_wc_parse_externals_description2 (which doesn't
> take a wc_adm_access_t, at least). Dealing with these two might be a
> little hairy.

OK, so the deal here is that svn_wc_prop_set2 does validation and
canonicalization on svn:* properties. I want to factor that out. The
toughest part is svn:eol-style checking: it looks at the MIME type,
and also tries to make sure that the file has consistent newlines at
all. It does this by opening the file and writing it to a
substituting stream (which is connected to an empty stream) and seeing
if there's an error.

I've added the following to svn_props.h:

/** Callback type used by @c svn_prop_canonicalize_svn_prop.
 * It should set @a mime_type to the value of @a SVN_PROP_MIME_TYPE
 * for the path passed to @c svn_prop_mime_type (allocated from @a
 * pool), and then write the contents of the file to @a stream.
 * (Currently, this is used if you are attempting to set the @a
 * SVN_PROP_EOL_STYLE property, to make sure that the value matches
 * the mime type and contents.)
typedef svn_error_t *(*svn_prop_canonicalize_get_file_t)
  (const svn_string_t **mime_type,
   svn_stream_t *stream,
   void *baton,
   apr_pool_t *pool);

/** Canonicalize the value of an svn:* property @a propname with
 * value @propval.
 * If the property is not appropriate for a node of kind @a kind, or
 * is otherwise invalid, throw an error. Otherwise, set @a *propval_p
 * to a canonicalized version of the property value. If @a
 * skip_some_checks is true, only some validity checks are taken.
 * Some validity checks require access to the contents and MIME type
 * of the target if it is a file; they will call @a getter with @a
 * getter_baton, which then needs to set the MIME type and print the
 * contents of the file to the given stream.
 * @a path should be the path of the file in question; it is only used
 * for error messages.
svn_error_t *svn_prop_canonicalize_svn_prop(svn_string_t **propval_p,
                                            const char *propname,
                                            const svn_string_t *propval,
                                            const char *path,
                                            svn_node_kind_t kind,
                                            svn_boolean_t skip_some_checks,

svn_prop_canonicalize_get_file_t getter,
                                            void *getter_baton,
                                            apr_pool_t *pool);

The idea is that in the wc propset case, the getter function would use
wc prop getting functions and print the file from disk to the given
stream, whereas for URL propsets, it would use svn_ra_get_file.

First of all, this seems like overkill. But it feels necessary to
preserve the current behavior for URL propsets.

Secondly, I'm running into a technical problem -- putting a reference
to svn_stream_t into svn_props.h make circular includes, since svn_io
includes svn_error includes svn_error_codes includes svn_props. (The
last is for no reason other than backwards compatibility -- it doesn't
even use it!)

So, either: how do I refer to svn_stream_t in svn_props.h, or what
design simplification am I totally missing?


David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 30 16:41:52 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.