[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN-4065 - server should enforce LF normalization for svn:eol-style=native

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 9 Oct 2019 17:14:41 +0000

Branko Čibej wrote on Wed, Oct 09, 2019 at 15:45:32 +0200:
> On 09.10.2019 15:00, Johan Corveleyn wrote:
> > 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.
> Validating contents (such as line endings based on svn:eol-style) is a
> perfect fit for hooks. Not normalising of course. :)

The repos layer validates svn:* revprops in svn_repos__validate_prop().

The FS layer doesn't do that validation.

The result of that is that old repositories with invalid svn:* properties can
be dump/load'd but can't be svnsync'.d

As to separation of concerns, that's a valid point, but we should be consistent
about what concerns belong where.  The validation of svn:* props and of
contents of files with svn:eol-style set belongs in the same layer, doesn't it?
Therefore, I think there are two options:
- These validation belongs in the repos layer.  The simpler/lower layer that
  doesn't do such validation is the FS layer.  svn:eol-style validation belongs
  in the repos layer.  (And if svnsync needs to bypass it, we'll design a way
  for it to do so.)
- These validations belong $elsewhere.  svn:eol-style validation will be added
  $elsewhere and svn_repos__validate_prop() will be moved $elsewhere.
My interpretation: I don't have an opinion yet, except that if we move the
validation out of the repos layer, I won't be quite as sure any more what the
difference between the FS layer and the repos layer _is_.  The FS layer exposes
a filesystem that's a 0-indexed array of trees [implemented by the DAG layer].
The repos layer does… what, exactly, on top of that?
Received on 2019-10-09 19:14:49 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.