RE: forbidding control characters prohibition in libsvn_repos in 1.7.10 (issue #4340)

> -----Original Message-----
> From: Daniel Shahaf [mailto:danielsh_at_elego.de]
> Sent: zaterdag 11 mei 2013 01:06
> To: C. Michael Pilato
> Cc: dev_at_subversion.apache.org
> Subject: Re: forbidding control characters prohibition in libsvn_repos in
1.7.10
> (issue #4340)
>
> C. Michael Pilato wrote on Fri, May 10, 2013 at 18:19:56 -0400:
> > On 05/10/2013 04:51 PM, Daniel Shahaf wrote:
> > > For issue #4340, we decided to block filenames containing \n in FSFS
and
> > > filenames containing control characters in libsvn_repos. (I agree
with
> > > that decision.)
> > >
> > > However, those changes are now nominated for backport towards 1.7.10
> in
> > > 1.7.x/STATUS, and I voted -0 on them, saying that "[the new]
> libsvn_repos
> > > restrictions [are] not suitable for introduction in a patch release"

---
> > > that is, that libsvn_repos-1.7.10 should not forbid creating fspaths
that
> > > contain control characters, because libsvn_repos-1.7.9 doesn't.
> > >
> > > Stefan asked to start a thread about that -0 vote, so here it is :)
> >
> > If you look at the "general idea" behind our versioning guidelines[1],
the
> > one relevant goal of the three presented is this one:
> >
> > "Upgrading/downgrading between different patch releases in the same
> > MAJOR.MINOR line never breaks code."
> >
> 
> Agreed.
> 
> > So long as we don't introduce new APIs or break the calling conventions
of
> > existing ones to accomplish this change, disallowing certain characters
in
> > repository paths does not affect the upgrade/downgrade-ability of the
> 
> Disagree.  Adding a validation to 1.7.10 that didn't exist in 1.7.9
> means that client code that worked with a 1.7.9 libsvn would stop
> working[1] when run with 1.7.10 libsvn.  That is precisely "Upgrading
> within the same minor line never breaks code", isn't it?
Taken 100% literally: If downgrading can never break code, we can not
backport any bugfixes. As downgrading to the unfixed version would
reintroduce the bug that we fixed.
(I'm not sure what we could ever backport in that world?)
If you read this as 'the public API can't change in a breaking way' I don't
see a real problem.
	Bert