On Wed, Oct 9, 2019 at 11:41 AM Julian Foad <julianfoad_at_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
Received on 2019-10-09 15:00:32 CEST