[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: modify-file within an added tree (r1356317) ; possibly rep-cache.db -related

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 10 Jul 2012 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

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)

Received on 2012-07-10 21:55:32 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.