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? Cheers, Daniel
