On 2016-10-18 17:01 (-0400), Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Tue, Oct 18, 2016 at 1:35 PM, Daniel Shahaf <d.s_at_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.
Received on 2016-10-19 18:08:39 CEST