> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: vrijdag 19 september 2014 16:50
> To: dev_at_subversion.apache.org
> Cc: Stefan Fuhrmann
> Subject: No no-op changes
>
> 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>
> <...>
To make things even stranger:
svnadmin dump will even show your property change.
But svnsync won't handle it as a change....
(And so svnrdump won't show it eiter)
And this is actually quite a common case created by older clients (e.g.
1.5-1.7) when using mergetracking. These clients didn't properly create
pristine properties on merged directories... so the existing properties were
locally stored as a change to an empty property list.
(Luckily this didn't cause many properties, because we don't allow reverting
just the properties)
This last bug was fixed in 1.8...
(And the svnsync problem was discussed on this list about half a year ago)
I'm not sure at which layer this is a bug, as the filesystem layer is pretty
consistent. I think I would say that the repos layer should catch this
case...
But then we have to decide if we should block non-changes or ignore them.
Blocking them will cause problems with older clients... (See problem I just
mentioned)
And I'm not sure if we really solve something by ignoring them.
Bert
Received on 2014-09-19 18:16:50 CEST