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, 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."
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
codebase. Further, we're merely guarding our entry points against these
troublesome paths, not croaking when we find them already in the repository.
As such, it's *not* the case that users find themselves with a new freedom
in 1.7.10 that, if exercised, will cause a downgrade to 1.7.9 to render
their repositories inaccessible.
In summary: I think the backport is fine.
Concession: It could be argued that the no-"\n"-in-FSFS change is
independent from the no-control-chars-in-libsvn_repos change. The former is
trivially defensible as a bugfix to guard against a demonstrable data
storage problem. The latter change is, IMO, the only possible controversial
one for a patch release. While I think both backports are fine, I wouldn't
strongly defend the latter.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-05-11 00:20:33 CEST