Re: No no-op changes
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 19 Sep 2014 17:54:44 +0100
Bert Huijben wrote:
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.
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, 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.
 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.
This is an archived mail posted to the Subversion Dev mailing list.