Johan Corveleyn wrote on Tue, Jul 10, 2012 at 21:54:39 +0200: > 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. >
First of all, even if there is such a bug then it's still a bug in the server that the commit was allowed (and it's doubly odd that the same commit is not allowed when done via svnsync rather than via rmuir's svn). > 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. Why would that have happened for only one of the numerous package-summary.html files in rmuir's commit? > 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? > No. https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/hooks/pre-commit (non-public link, sorry) > [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
