On 19.09.2014 16:49, Julian Foad wrote:
> 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.
I really don't see a problem here.
You have to ask yourself what the intent of "diff" and "log" actually is:
* Diff shows differences between trees: if there are none, it should
show nothing.
* Log, on the other hand, displays an audit trail.
As a repository admin, or as a project manager, I definitely *do* want
to know when someone made a change, and what the change was, even if the
change itself results in an empty diff.
In other words, we're looking at two completely different use cases,
both valid. You're proposing to make one of these use cases invalid; to
in fact completely ignore it. By doing so you're ignoring a significant
proportion of our user base.
We should do exactly the opposite! We should make sure that even no-op
changes always get recorded and reported consistently. You have to
remember that repository history is not only about tree snapshots, it's
also about intent and results. In other words, an audit trail is just as
important as actual repository contents.
Let's not revert to following git's policy of being a glorified patch
manager instead of a version control system.
-- Brane
Received on 2014-09-20 09:56:32 CEST