subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Hartman <hartman.nat...@gmail.com>
Subject Re: SVN-4065 - server should enforce LF normalization for svn:eol-style=native
Date Fri, 11 Oct 2019 02:51:09 GMT
On Wed, Oct 9, 2019 at 7:12 PM Johan Corveleyn <jcorvel@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
utilities:
https://en.wikipedia.org/wiki/BusyBox
 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.

Nathan

Mime
View raw message