I don’t think you have to wait until commit time: You could verify the commit base revision’s properties + changes. In the cases where the properties change before commit, the commit would fail for being out of date.
Bert *From:* Branko Čibej *Sent:* December 10, 2012 12:26 AM *To:* dev@subversion.apache.org *Subject:* Re: enforcing LF-normalization for svn:eol-style=native files (issue #4065) On 10.12.2012 00:08, Johan Corveleyn wrote: > 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 :-). The first obstacle is that the server does not interpret properties.[1] Therefore, you'd have to implement this check at transaction-commit time, because there's no earlier point where you're guaranteed to have all node properties at their final values. This implies that the time to reject a commit would be proportional to the size of the commit (which isn't the case when it comes to conflict detection). All properties are interpreted by clients. A buggy client will cause cause problems for other users, so the best course of action is to report the bug (to SvnKit in this case?). Also note that you're using a much too strong term when you talk about "corrupted files" in this case. There's nothing corrupted about them. -- Brane [1] Not strictly true since mod_dav_svn will look at svn:mime-type when serving the content at its default, unversioned URL; but it doesn't actually interpret the value. -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
