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
Received on 2019-10-09 12:41:36 CEST