subversion-dev mailing list archives

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



View raw message