On Tue, Jul 10, 2012 at 2:43 PM, Robert Muir <rcm...@gmail.com> wrote: > On Tue, Jul 10, 2012 at 2:17 AM, Trent Nelson <tr...@snakebite.org> wrote: >> >> I've also never come across this in the wild. We should definitely ping >> `rmuir` to find out how he committed that revision; platform, version, etc. >> > > Hi Trent: > For this commit, I did a 'cp -r ' of the folder from our release > candidate to my checkout, and then 'svn add', followed by 'svn > commit'. > > Here's my system info (let me know if you need more): > > uname -a: > Linux beast 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC > 2012 x86_64 x86_64 x86_64 GNU/Linux > > svn --version: > svn, version 1.7.2 (r1207936) > compiled Dec 1 2011, 12:30:57
I'm wondering if there isn't a client side bug here, which really caused it to send a modify-file inside an add-without-copyfrom directory. I'm specifically thinking in the direction of "file translation" stuff and svn:eol-style=native. These files have svn:eol-style=native. But that by itself can't be the problem, because a lot of files in this commit have eol-style native, and only one file has the "modify" problem. Still, I know that if a client fails to "eol-normalize" a file with eol-style=native, this can cause weird problems (files showing up as modified even though you haven't modified them [1] -- see also [2]). What happens if, for some reason, the client fails to eol-normalize a newly added file, within an added-without-copyfrom directory (i.e. client sends CRLF line termination to the server instead of LF as it should)? Maybe that causes a modify-file? Or maybe something like this (a mixup in file translation) happened during the server-side MERGE? Now, it's unlikely that this is what happened here (the base file of the dreaded package-summary.html@1356317 is correctly LF-terminated -- and the client platform is unix, so should have been LF-terminated from the start (except if the 'cp -r' was done from a network drive that was also used on a Windows system or something like that)). But still, eol-translation can cause weirdness ... Oh, and there isn't anything in the pre-commit hook which could possibly modify transactions in mid-flight, is there? [1] http://svn.haxx.se/users/archive-2011-10/0291.shtml [2] http://subversion.tigris.org/issues/show_bug.cgi?id=4065 (server should enforce LF normalization for svn:eol-style=native files) -- Johan
