[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: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 10 Dec 2012 06:35:40 +0000

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


 *From:* Branko Čibej
*Sent:* ‎December‎ ‎10‎, ‎2012 ‎12‎:‎26‎ ‎AM
*To:* dev_at_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.s_at_daniel.shahaf.name>
>> 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
Received on 2012-12-10 07:36:19 CET

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

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