[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

No no-op changes

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 19 Sep 2014 15:49:56 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.