On 2016-10-18 17:01 (-0400), Johan Corveleyn <jcor...@gmail.com> wrote: > On Tue, Oct 18, 2016 at 1:35 PM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > Branko Äibej wrote on Tue, Oct 18, 2016 at 13:08:37 +0200: > >> It is. I don't think there's any way we can /not/ make it backwards > >> incompatible, given the current implementation. Which is why I think we > >> should just admit that current behaviour is a bug. > >> > >> Either that, or introduce a new property that behaves sensibly. > > > > Some IRC discussion lead us to svn_prop_name_is_valid(), which requires > > that the first character of a property name be alphabetic or colon or > > underscore. > > > > Brane therefore proposes «*.txt == propname=propval» for the "override" > > syntax, and keep «*.txt = propname=propval» for the "overlay" syntax. > > > > This change would be backwards compatible: this syntax does not have > > a meaning currently. 1.9 clients just ignore it. > > > > We can bikeshed about finding a syntax that looks less like > > a C comparison, of course. We can't use =: because property names can > > start with a colon, we can't use := because filename patterns can end > > with a colon, but any other option is open. > > Great idea. And I like that color of bikeshed :-). > > Another option would be to introduce a "subtract" syntax, with =- or > =!, but I don't know if that would be easier / better for the user (in > that case, he'd have to specify the *.txt pattern two times, to > subtract svn:eol-style with =!, and add svn:mime-type with =).
All these variants seem to suffer the same problem, old clients will set the properties after the first semicolon: *.txt == prop1 ; prop2 There is a way to prevent that, filenames do not contain slashes: *.txt /= prop1 ; prop2 This one passed my tests with an "old" client. - Martin
