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
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
Received on 2019-10-11 04:51:35 CEST