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
