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.
