subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject No no-op changes
Date Fri, 19 Sep 2014 14:49:56 GMT
  * 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

$ 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 

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.


- Julian

View raw message