Re: Bad property name

On Tue, 08 Aug 2006, C. Michael Pilato wrote:

> David Glasser wrote:
> > On 8/8/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> >
> >> C. Michael Pilato wrote:
> >> >>2. Why does it not check the property name before starting the editor?
> >> >
> >> > Hrm. Now there's a good question. I'd call that a bug.
> >>
> >> Aha. The is-valid check happens down in libsvn_client, well after the
> >> editor has been used to get a property value. I think we should
> >> expose the
> >> is_valid_propname (and similar) checks through the svn_client.h API, and
> >> teach the command-line client to use them before firing up the editor.
> >
> >
> > Out of curiousity, is it intentional that propname validity checking
> > happens at the svn_client level and not at a lower level?
> >
> > I was actually considering sending a message about a similar issue
> > just this week, after discovering a bug in svk where it misparsed the
> > auto-props configuration section and silently set properties with
> > names like " svn:eol-style" (with a leading space). Having any "valid
> > property name" API at all would be great, but does it make sense to
> > allow weird property names at the repository level? (I guess you have
> > to for compatibility reasons now.)
>
> I'm pretty sure I've argued this (or something very similar regarding path
> names) *very* recently. Sure, we could teach libsvn_repos to do similar
> checks (though, keep your grubby hands offa the libsvn_fs layer, bucko!).
>
> Of course, doing this kind of check *only* at the repos layer instead of
> also at the client side is counterproductive. Besides delaying sanity
> checks until well after real user work has been done, it also defeats one of
> the points of the checks in the first place -- to keep data that can't be
> transported via our XML protocol (ra-dav) off the wire entirely.

+1 on factoring the API into a libsvn_subr routine, and doing the
check early during a 'propedit' (rather than too late), and in the
appropriate libsvn_repos API.