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

Re: SVN-4065 - server should enforce LF normalization for svn:eol-style=native

From: Nathan Hartman <hartman.nathan_at_gmail.com>
Date: Thu, 10 Oct 2019 22:51:09 -0400

On Wed, Oct 9, 2019 at 7:12 PM Johan Corveleyn <jcorvel_at_gmail.com> wrote:

> But I think this kind of content validation is different from
> "application-level content validation", like "follow coding style X",
> or "commit message should contain an issue key", or "I want to enforce
> that .c files have svn:eol-style=native". Such application-level
> content rules have no effect whatsoever on the workings of SVN itself.
> SVN clients don't care about those, only the applications (IDE, users,
> ...) do.
> In contrast, having a "non-LF-normalized with svn:eol-style=native" in
> the repository breaks "svn diff" (all lines shown as different) and
> "svn status" (if timestamps mismatch, contents are checksummed, and
> the file shows up as modified while it isn't -- causing confusion and
> even worse, spurious tree conflicts).
> So in my eyes this is more of an obligatory validation, to preserve
> the sanity of your "svn ecosystem".

I don't (yet) have an opinion whether this should be a hook or implemented
internally. But when you explain it this way, I suppose I might gravitate
towards obligatory validation. I'm undecided so far because that seems to
cause some headaches in terms of legacy data and a path forward. I need to
learn more about it.

On the separate question of a standardized C-coded binary svnhooks program,
I like this idea. I see it as a "busybox"[1] of svn hooks. I like this
because many (perhaps most?) installations could use it rather than coding
up their own custom scripts, reducing setup difficulty on admins and
hopefully reducing errors and misunderstandings. I like standardization.
But I'm probably repeating everything that was already said. :-)

It is important to let admins continue to write their own scripts when they
have custom needs but I'm sure that's the intention anyway.

[1] Busybox is a single executable that implements several standard UNIX
 I see a "svnhooks" program as being an analogue of that because it could
consolidate all the existing commonly used hook scripts into one program.

Received on 2019-10-11 04:51:35 CEST

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.