On Sun, Dec 9, 2012 at 11:43 PM, Daniel Shahaf <d...@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
