Re: No no-op changes

Bert Huijben wrote:
[...]
> I'm not sure at which layer this is a bug, as the filesystem layer is pretty
> consistent. I think I would say that the repos layer should catch this
> case...

Actually it is a FS layer problem. svn_fs_paths_changed2() returns paths which have in fact not had a change. (I don't know if this is the only place where we get it wrong, but it is the most obvious one.)

> But then we have to decide if we should block non-changes or ignore them.
>
> Blocking them will cause problems with older clients... (See problem I just
> mentioned)

We should certainly not throw an error, if that's what you mean by "block".

We should allow a no-op "change" to be requested, and we should preferably store no change[1], and as a second-best option we could at least get the FS layer API right by reporting no "change" through the API, although this would still leave the on-disk storage non-canonical.

> And I'm not sure if we really solve something by ignoring them.

What we solve is the problems caused by inconsistency. At present (on the 'move-tracking-2' branch) I am trying to interpose 'shims' in the commit and update editors. The shim stores up the set of changes being driven into the editor interface and then re-plays those edits in a batch. It does not replay no-op changes; to do that I would have to write extra code to remember exactly what editor methods were called rather than just what the overall result was. And yet I get some test failures because some tests are written to expect the specific behaviour of the leaky abstraction that we have provided.

- Julian

[1] Again, to be clear, I don't mean no empty revisions, I'm talking about a change of properties or of text of a node.
Received on 2014-09-19 18:55:18 CEST