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

Re: enforcing LF-normalization for svn:eol-style=native files (issue #4065)

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 10 Dec 2012 00:08:26 +0100

On Sun, Dec 9, 2012 at 11:43 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 21:15:24 +0100:
>> 2) Am I the only one who wants to protect his repository against this
>> corruption? Judging from [1], I don't think so. It doesn't make sense
>> that everyone starts writing this pre-commit hook, for something that
>> IMHO is an obvious anti-corruption protection. I think every
>> repository out there deserves to be protected against this.
>>
>
> FWIW, I suggested a hook because you could implement that in about
> 5 minutes, whereas doing a C code change would take at least 10 times
> that (and several weeks if you have to wait for it to appear in a 1.7.x
> release that you can install at $WORK). I won't object to C code
> verifying the svn:eol-style invariant.

Thanks. And your pre-commit hook example is much appreciated.

For the moment I get the impression that it's not really doable /
desirable to implement this in the repository. At least until now
no-one has suggested how it could be done, and I don't know enough
myself about the server-side / back-end to figure it out :-).

(side-note: I don't want to rush anything and get it backported to a
1.7.x release. For the moment I can manage (I watch the problem from
an asynchronous post-commit hook, and fix it as soon as it happens,
which is only a couple of times a year in our repos). But I'm
interested in a long-term solution to this, so this wart can be
eliminated :-)).

As for my 1st concern, about the slowness of the pre-commit hook
validation, it might be possible to make it faster if both 'svnlook
pg' and 'svnlook cat' would support multiple targets.

-- 
Johan
Received on 2012-12-10 00:09:20 CET

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