Hello,
With more explanation of how properties work now, I agree that my patch is broken.
I can implement a FSM to get the properties the right way.
I had considered using XML output, but didn't want to add needless complexity, especially to old Perl code. I may have to rethink that if the network layer or repos/fs hands me property names with leading spaces.
It should be possible to try and inject leading spaces to the property name without the client over the network. I'm not sure how to attempt something similar with the repos/fs layer.
Regards,
Leo
________________________________________
From: Ben Reser <ben_at_reser.org>
Sent: Friday, February 28, 2014 8:16 PM
To: Leo Davis; dev_at_subversion.apache.org
Subject: Re: [PATCH]: fix check-mime-type.pl for changes to 'svnlook proplist' output
On 2/28/14, 7:07 PM, Ben Reser wrote:
> To that end I'd suggest that you implement a finite state machine to parse
> this. With the following states:
>
> Starting state is fileheader.
>
> fileheader: Sanity check state by checking that line has zero whitespace at
> start (tempting to use /^Properties/ but that breaks with non-English locales).
> Next state is propname.
>
> propname: Sanity check state by checking that line has at exactly 2 leading
> spaces (not sure if we allow leading whitespace in property names, the client
> disallows it and I think it's hard to marshal it over the network proptocols
> but might still be possible with repos/fs layer). Next state is propval.
>
> propval: Has at least 4 leading spaces. Only 4 leading spaces are removed from
> the start of each line before adding to the property value. Next state is
> either propval, propname, or eof. Determined by looking at next line (number
> of leading spaces or eof result).
>
> eof: End parsing.
>
> Can you take on implementing the above?
>
> Note that the above states does not account for --show-inherited-props, but I
> don't think that's a problem since the hook script doesn't use that. To
> support it you'd need to allow multiple fileheader lines (Inherited line is
> followed by from line) and empty line ahead of fileheader lines. So you'd have
> to look ahead up to two lines for that.
>
> Side note if it is possible to get property names with leading spaces in them
> it makes the output of svnlook proplist --verbose impossible to parse reliably.
> Sadly our old format had a clearer problem with this because setting another
> property with multiple lines could end up being interpreted as a property.
> E.G. say I sent a property named "zzz-bypass-mime-check" with the value:
> line1
> svn:mime-type : expected/type
>
> The name zzz is to make it be the last property the script sees. At least with
> fsfs we seem to always return the properties in alphabetical order. I'm not
> seeing any sorting but I suspect we're putting property values in the
> representation in a stable order and so we end up with them coming out in the
> same order.
Forgot to mention. You can always use --xml. But then you need a full fledge
XML parser. Which brings its own problems but wouldn't have these issues.
Received on 2014-03-02 04:54:02 CET