No no-op changes

Summary:
  * A "no-op change" is not a change.
  * Subversion should not report a "no-op change" as a "change".
  * We should bear this in mind when designing and reviewing.
  * Fixes are needed in a few places.

I noticed recently that we handle "no-op changes" inconsistently. By a "no-op change" I mean, for example, a request to set property 'p' to value 'v' when it already had value 'v'.

[[[
$ svn propget p $REPO/trunk -r5
v

$ svnmucc -U file://$PWD/repo -m "" propset p v trunk
r6 committed ...

$ svn diff --summarize -c6 $REPO
[no output]

$ svn log -vq --xml -r6 $REPO
<...>
<path
   kind="dir"
   action="M"
   text-mods="false"
   prop-mods="true">/trunk</path>
<...>
]]]

This output says that there was a property "modification" in r6 ... and yet shows no changes.

Why is this wrong? Fundamentally, Subversion versions tree snapshots. A change is defined as the difference between two tree snapshots. In this sense there is no such thing as a no-op change: it just means no change.

Many of our APIs, including for example a "commit editor", allow specifying a new state which may be the same as the old state. That is fine. But anywhere we receive a new state and blindly report it as a "change" regardless of whether it differs from the previous state, that is wrong. The fact that we do sometimes record such an event -- and such events are stored in repositories already -- does not make it a meaningful event; it is an implementation artefact that happens to leak out at one or two places.

I talked about this with Stefan Fuhrmann. We think the main place where a fix is needed is in the repository-side commit processing. It could elide no-op changes from a transaction before committing it, or maybe just remove the change entry from the "changes" list so that new no-op changes don't show up in 'log'. We also need to filter out no-op "change" records when reading old repository data.

The ability to commit a new revision with no changes is fine -- a new revision number in Subversion does not imply a change.

Can someone please confirm this all makes sense. I'll then identify specific bugs to fix.

Thanks.

- Julian
Received on 2014-09-19 16:57:09 CEST