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.
