On Wed, Oct 9, 2019 at 7:12 PM Johan Corveleyn <jcor...@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
