On Sat, May 11, 2013 at 1:05 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> 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
> > > 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]
> > > restrictions [are] not suitable for introduction in a patch release"
> > > that is, that libsvn_repos-1.7.10 should not forbid creating fspaths
> > > 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,
> > 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."
> > So long as we don't introduce new APIs or break the calling conventions
> > existing ones to accomplish this change, disallowing certain characters
> > 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 when run with 1.7.10 libsvn. That is precisely "Upgrading
> within the same minor line never breaks code", isn't it?
My understanding is that an newline in a file path will
always corrupt your repository, i.e. it has never been
"working" in a strict sense. You may have gotten lucky
if the newline was at the very end of the path, the stars
were in the right position etc. but chances are that it
would still bite you further down the road.
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Received on 2013-05-11 15:14:02 CEST