On Wed, Oct 9, 2019 at 11:41 AM Julian Foad <julianf...@apache.org> wrote: > > Johan Corveleyn wrote: > > I think that was the conclusion from those threads. I.e. it would be > > best if we developed a standard "svnhooks" program that can be invoked > > from the pre-commit hook (and not try to implement this directly in > > the repos layer). At least, after those svnhooks suggestions no-one > > objected, so I assumed silent consensus about that way forward :-) ... > > Silence meant "errm... what?"
I disagree. On this list silence means "no objections". If someone wanted to say "errm... what?", they should have mailed it. In that very thread, 7 years ago, it seemed quite clear that consensus was gravitating towards "don't solve it in the repos layer, but in a pre-commit hook": * Daniel first posted a simple script for pre-commit hook validation: https://svn.haxx.se/dev/archive-2012-12/0180.shtml * Brane said the only sane place to do it was in pre-commit hook: https://svn.haxx.se/dev/archive-2012-12/0182.shtml * Brane also suggested to write it in C: https://svn.haxx.se/dev/archive-2012-12/0191.shtml * Ivan suggested to create a separate program for it "svnhooks", with this concrete "rule" as a first use case for a more general tool: https://svn.haxx.se/dev/archive-2012-12/0202.shtml * Ivan specified his idea a bit further here: https://svn.haxx.se/dev/archive-2012-12/0217.shtml During that entire discussion thread the only objections raised were about "enforcing it in the repos layer / server directly". No-one objected to the proposal(s) to solve the issue via pre-commit hooks. Sound pretty consensus-y to me. ... > That means we have to design it in such a way that only "client commits" > are affected, and "server tools" such as sump/load are not, because we > can't have them suddenly start failing to load existing repository data. Yes, and hooks can do that. You're arriving at the same conclusion as the thread 7 years ago. > Are "svnrdump" and "svnsync" client-layer or repos-layer tools, for > these purposes? We don't yet have a formal way to distinguish and use > "repos-layer" tools through our client-server (RA) interface. So at the > moment I suppose we might say that ("de facto") all interactions through > the RA interface are deemed to be client-layer interactions. We could > consider an enhancement to enable "repos-layer" interactions to be > performed over RA with suitable authorization. We probably ought to > file that as a future enhancement issue. > > Currently we have "svn commit" and other client-layer operations, vs. > "svnadmin load" as the main repos-layer (server side) interaction. > > "svnadmin load" has these options: > --use-pre-commit-hook > --use-post-commit-hook > --normalize-props > --bypass-prop-validation > > To me, this looks like a crude attempt to allow it to support both > client-layer and repos-layer modes, but with no overall mode switch so > the user has to think about the implications of each individual sub-switch. > > We never spelled out the role of commit hooks. Therefore presumably > some commit hooks are used for client-side purposes (enforcing rules > like LF normalization and log message formats, etc.) and some for > server-side purposes (logging, backups, mirroring to svnsync, etc.). > The option to enable or disable all commit hooks seems misguided: > instead it would seem more appropriate to categorize hooks into client > and server roles, and have "svnadmin load" apply only those in the > server role. > > Is two roles of hooks something it makes sense to introduce? Or could > we clarify the current situation, document it? > > It looks to me like "enforcement of the standard svn client's rules" is > an option we would ideally like to provide to server operators. How > would this be defined more precisely? How should we design it to cope > with different client versions, whose rules have changed a few times? You're pulling this way out of scope. Issue SVN-4065 is very concrete and specific, and a concrete proposal was made on how best to solve it. You're using it to open a much broader architectural discussion. Which is fine of course, and I think quite interesting. But that shouldn't block progress for SVN-4065 in the way which was proposed 7 years ago, and which still seems the best way (via a utility program that can be invoked from hooks, where our hooks still have the same semantics / confusions / shortcomings / ... as today). That being said, maybe that svnhooks utility program (Ivan's proposal) could be used to introduce a way to separate those different roles that hooks serve. Ivan hinted a bit in that direction in his post there. From https://svn.haxx.se/dev/archive-2012-12/0217.shtml: > svnhooks configuration file has separate section for each policy. For example: > [[[ > [check-eol-normalization] > enable = yes > > [rev-propchange] > enable = yes > users = svnsync > > [edit-log-message] > enable = yes > users = admin, @author > ]]] I agree this should be thought through, with a good design (a "users" field might not cut it -- perhaps something else). It's clear that the proposal needs further design work. -- Johan
