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-01 04:16:45 CET