On Tue, Jul 10, 2012 at 2:43 PM, Robert Muir <rcmuir_at_gmail.com> wrote:
> On Tue, Jul 10, 2012 at 2:17 AM, Trent Nelson <trent_at_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_at_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
Received on 2012-07-10 21:55:32 CEST