[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: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Mon, 10 Dec 2012 01:24:40 +0100

On Mon, Dec 10, 2012 at 12:26 AM, Branko Čibej <brane_at_wandisco.com> wrote:

> 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>
> 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).

Well, if we really want to implement such a feature,
we may as well be a bit more clever about it: While
writing incoming file contents to the protrev file, we
may determine its NL style as we go and store the
result. The latter could then be compared to the props
setting during commit time.

-- Stefan^2.

Certified & Supported Apache Subversion Downloads:
Received on 2012-12-10 01:25:14 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.