On 03/27/2013 11:03 AM, Stefan Sperling wrote:
> On Wed, Mar 27, 2013 at 10:52:04AM -0400, C. Michael Pilato wrote:
>>> I think we'll have to block these paths at the FS layer.
>>
>> If FSFS is fundamentally unable to support these types of paths, then sure,
>> let's go ahead and protect against the failure at that level. But please
>> don't overreach here -- block only the paths that FSFS simply cannot deal
>> with. There have been other tools built atop the FS layer in the past
>> (wikis, etc.) and could be in the future -- this is, after all, why we have
>> distinct FS and repos APIs -- and we shouldn't be artificially limiting what
>> folks can do with the that API.
>
> 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"?
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.* 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 we already
catch flak as a community from time to time for the limitations in our
system forced upon us because of implementation decisions we've made (no
control characters because XML is unhappy; no colons in certain properties
because WebDAV can't hack it; etc.)
I get that we want Subversion (as a version control system, end-to-end) to
work. But the FS layer should not inherit superficial limitations simply
because enforcing them in the right place is too hard.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-03-27 16:21:27 CET