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

Re: Huge diff for one-line change in ASF repository

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sun, 20 Nov 2011 01:57:13 +0100

On Sat, Oct 15, 2011 at 2:18 AM, Ryan Schmidt
<subversion-2011a_at_ryandesign.com> wrote:
> On Oct 14, 2011, at 18:52, Johan Corveleyn wrote:
>> Ah, but git-svn doesn't seem to honor the invariant that files with
>> native eol-style *must* be converted to LF by the client. By not doing
>> this, they break things for every other svn client using the same
>> repository. So this is clearly a bug in git-svn. Of course, to avoid
>> flames, we should probably first escalate the problem to the git-svn
>> people, to get this bug fixed (or maybe it is already fixed?).
> It's not just the svn:eol-style conversion that git-svn doesn't do; I hear it doesn't do svn:keywords normalizations either. It's the responsibility of the client to ensure that, for example "$Id: foo bar baz $" gets normalized to "$Id$" before being sent to the repository to be committed. I was told that the git people don't believe in the kind of munging that Subversion does for eol-style and keywords and therefore they don't want to implement it. I say fix the server to issue an error when a client tries to commit data that is not normalized in the required fashion. Force them to comply, and stop distributing software that does not behave correctly.

Almost forgot about this, but now I've finally created an issue for
this in the issue tracker:

http://subversion.tigris.org/issues/show_bug.cgi?id=4065 (server
should enforce LF normalization for svn:eol-style=native files)

I only mentioned LF-normalization for svn:eol-style=native (actually I
forgot the suggestion that keyword-expansion is in the same boat
here). Maybe another issue should be opened for server-side
enforcement related to keyword expansion...

Received on 2011-11-20 01:58:07 CET

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

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