No no-op changes
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 19 Sep 2014 15:49:56 +0100
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'.
$ svnmucc -U file://$PWD/repo -m "" propset p v trunk
$ svn diff --summarize -c6 $REPO
$ svn log -vq --xml -r6 $REPO
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.
This is an archived mail posted to the Subversion Dev mailing list.