On 04/03/2013 10:25 AM, Stefan Sperling wrote: > Well, the argument goes like this: > > Subversion cannot handle \n in filenames at many levels. > > It was found that the FSFS layer cannot handle it without repository > corruption, and it was pointed out that e.g. the unidiff format and the > Subversion dump file format have problems with \n in filenames, too. > > So preventing filenames with \n in Subversion in general seems to be > a good thing to do. Since only FSFS currently rejects \n, BDB users > are left unprotected from harmful effects of \n outside the filesystem > layer unless we make the BDB layer reject such paths as well (which you > don't agree with) or make the repos layer reject such paths (which it > does as of r1461760 and which we should backport IMO). > > Next, others have pointed out that similar issues can be caused by > other control characters (such as \r) on some platforms, and also > that libsvn_client has always been rejecting paths which contain any > control characters. Consistency is a good thing, and making Subversion > servers forbid control characters in filenames outright addresses our > concerns about \n as well. > > Does that make sense?
Yup. I'll upgrade my response for this portion to +1. Thanks for making such a clear and well-articulated argument! -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
