On Sat, Oct 15, 2011 at 2:18 AM, Ryan Schmidt
> 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:
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