On 09.10.2019 11:50, Julian Foad wrote: > Julian Foad wrote: >> 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. > > I want to add something stronger. It would be a mistake to push > validation of file content against property values into the repos > layer as a new rule about the allowed semantics of repository contents. > > It's important to have different levels in the architecture with > strongly defined characteristics, generally with lower layers having > simpler semantics. Currently the repos layer does not interfere with > file content at all. That is Good.
Couldn't agree more. There's a rather large can of really ugly worms hiding in there and we do not want to look for it, let alone open it. > The repos layer to a large extent transparent to properties and their > values, though not so much: it has some validation and even > "normalization" of "svn:" property names and values. I feel this is > generally Bad; there is some room for repos-layer knowledge of > properties but we should have separated the concerns better. Does the repos layer actually normalize svn: properties? I know 'svnadmin load' can, but I don't believe the repos API does that? -- Brane
