On Sat, May 11, 2013 at 3:24 PM, Stefan Sperling <s...@elego.de> wrote:
> On Sat, May 11, 2013 at 03:13:30PM +0200, Stefan Fuhrmann wrote: > > You may have gotten lucky > > if the newline was at the very end of the path, > > No, not at all. See the original problem report which was about > such a case: http://svn.haxx.se/dev/archive-2013-03/0415.shtml > First off, I'm +1 on fixing that in 1.7.x. But you omitted my astrology reference in the citation. FSFS stores paths in noderev records and changed path lists. The respective parsers are somewhat forgiving: * Empty lines at the end of change path lists get ignored * Changed path lists will only be read for "loggy" (log, merge) and "dumpy" (dump, verify) operations. They are not required for e.g. checkouts. * The path element in a noderev record is the last mandatory one - the following copyfrom and minfo-* props are optional. The parser will simply stop at a newline. So, committing file paths that end with a newline and with just one file / rev, chances are that the corruption will only surface in an inconsistent path name (reported w/o newline by change lists and noderev but seen with newline in the directory entry). Getting newlines at the end of a file name is most likely due to some automated process / script not properly splitting its input stream. And those workflows might accomplish their goals despite corrupting the repo. -- Stefan^2. -- *Join one of our free daily demo sessions on* *Scaling Subversion for the Enterprise <http://www.wandisco.com/training/webinars>* * *
