On Wed, Mar 27, 2013 at 11:20:54AM -0400, C. Michael Pilato wrote:
> On 03/27/2013 11:03 AM, Stefan Sperling wrote:
> > That's fine. The fix I've committed and proposed for backport applies
> > the large hammer and blocks any control characters. If there's a case
> > to be made for relaxing this check I'm happy to do that.
>
> Sorry, but I'm -1 on that change. How did this expand from "trailing
> newlines" to "any control character"?
An IRC discussion with Ben:
http://colabti.org/irclogger/irclogger_log/svn-dev?date=2013-03-26#l479
Who said:
"I'm not inclined to spend a bunch of time thinking through all the
implications of the control characters that we already don't allow
in the client lib."
I agree there. I also didn't want to test all control characters
to see if FSFS can handle them. It seems safer to reject them outright.
> Look, the FS allows things that the repos layer does not. For example, it
> doesn't care about property encoding or formats, where the repository layer
> does. *That's by design.*
Sure, but then we need an implementation that conforms to that design.
We clearly don't have one, else it wouldn't choke on newlines.
Fixing the implementation is going to be hard and we aren't even
sure if any user of the API really cares.
> It's perfectly okay for us to tell folks that if
> they modify their FS with something other than Subversion and end up with
> data that Subversion doesn't like, that's their own problem.
But (at least) with newlines, they can end up with data that the filesystem
implementation itself doesn't like. So the API becomes entirely useless
to them if they want to store filenames which contain newlines.
What about:
- We make the FS layer check for newlines (because we know FSFS can't cope)
- We make the repos layer check for control characters (because the
Subversion clients does, too, and we had problems with third-party
stuff like git-svn committing stuff which svn clients couldn't deal
with in the past)
That's some additional work, but I'm willing to do it.
Received on 2013-03-27 16:40:30 CET