subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject Re: SVN-4065 - server should enforce LF normalization for svn:eol-style=native
Date Wed, 09 Oct 2019 09:41:08 GMT
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:

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

View raw message