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?"
Not sure if this is a good bite-sized task for interested hackers though ...
Though it's quite well-contained (develop a separate (small) program
with a configuration file, depending on existing server-side API's),
and we have a clear use case to start with.
Glad we're reviewing this old issue.
What do you envision the purpose/scope/role of this program should be?
It's easy to suggest a facetious answer: "a collecting place for random
bug fixes". Of course not.
Seriously, the question that needs addressing for this issue is at what
level the LF normalization is to be enforced in a Subversion system
(deployment) in general. So far it has been client-side, with the
implication that different clients are expected but not forcibly
required to co-operate.
The first implication of that is that clients should handle gracefully
the case where repository data is not in fact normalized how they
expected it. That's one actionable conclusion.
If we want to change this to a repository-level rule, then that implies
we are changing the repository semantics in a backward-incompatible way
and we would need to address that (using a format number bump, and an
upgrade/migration path). We could discuss that path but I don't think
anyone's currently pushing for that and I don't see good reason to do
so, so let's leave that aside.
It seems we want to keep the design where this normalization is a
client-side rule, but now we want to provide additional server-side
enforcement of the client-side rule. We must still in odd cases allow
server tools (like dump/load) to continue working with repository
content that doesn't obey that rule.
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.
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?
- Julian
