Johan Corveleyn wrote on Tue, Jul 10, 2012 at 21:54:39 +0200:
> 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.
>
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_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?
>
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
Received on 2012-07-11 15:43:39 CEST