You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2014/09/19 16:49:56 UTC
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>
<...>
]]]
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
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Shahaf wrote:
> Should we provide an "official" way to create an empty revision? That
> is, a revision whose changed-paths list is empty? [...]
I replied to this in a new thread, "Official way to create an empty revision".
- Julian
Re: No no-op changes
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Fri, Sep 19, 2014 at 16:34:04 +0100:
> Andreas Stieger wrote:
> >> 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.
> >
> > These no-op change scenarios come to mind:
>
> > * empty revisions via svndumpfilter
>
> Empty revisions are not a problem.
Should we provide an "official" way to create an empty revision? That
is, a revision whose changed-paths list is empty?
Use-cases:
1. Suppose last backup is r100 and revisions r101:r105 were lost; then
after restoring the backup, the admin would create 5 empty revisions.
2. Force an empty revision for whatever reason, such as to make the
revnums sync to something:
2.1. See r3 of the regression test merge_tests.py#125 svnmucc_abuse_1().
2.2. W hen loading our repository to the ASF repository, if Joe had
created 26 empty revisions, then The Offset would have been 840100
rather than 840074, which would make our mental math easier.
Daniel
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
Andreas Stieger wrote:
>> 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.
>
> These no-op change scenarios come to mind:
> * partial repository replication via svnsync due to visibility
You mean resulting in empty revisions? Not a problem.
I repeat from my original post: "The ability to commit a new revision with no changes is fine -- a new revision number in Subversion does not imply a change."
> * empty revisions via svndumpfilter
Empty revisions are not a problem.
> * dumps with no-op changes would become invalid?
No.
- Julian
Re: No no-op changes
Posted by Andreas Stieger <an...@gmx.de>.
> On 19 Sep 2014, at 15:49, Julian Foad <ju...@btopenworld.com> 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.
These no-op change scenarios come to mind:
* partial repository replication via svnsync due to visibility
* empty revisions via svndumpfilter
* dumps with no-op changes would become invalid?
Andreas
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>>> The diff reports have
>>> no equivalent of log's text-mods/props-mods but they do communicate that
>>> a new node was created. The diff client could choose to output some
>>> sort of "new node" message.
>>
>> (I assume you mean "new node-revision".)
>
> More that the client could report some sort of "new version of file"
> message.
>
>> You have observed this
>> correlation between new node-revs and editor method calls in the
>> current typical Subversion software configuration. The client should
>> not assume that an "open-dir" or "open-file" editor method call means
>> a new node-revision in the file system. Node-revisions are meant to be
>> a private implementation detail of the repos or FS layers.
>
> The RA layer is public API. At present the RA layer invokes open_file
> in the client's delta editor when there is a no-op text change so this
> is a visible to the client.
In a typical Subversion software package built from client and server software libraries supplied by us, yes, that behaviour happens, among other things that happen.
> Our client chooses not to report this to
> the user but other clients might choose differently. It's not entirely
> clear what the client can assume about an open_file that is not followed
> by either apply_textdelta or change_file_prop
Quite.
> but it would not be
> unreasonable for a client to report that it received open_file.
And my point is it *would* be unreasonable because (a) users have no use for being told merely that a certain method was invoked in the software interface; and (b) we have assigned no meaning to this event other than, in my opinion, by happen-stance. In particular, other implementations of any software layer involved in the procedure may produce different behaviour.
I want to say that it is very important that we distinguish between deliberate, meaningful, useful behaviour and happen-stance behaviour that nobody wants but that happens to occur in some conditions.
- Julian
Re: No no-op changes
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@btopenworld.com> writes:
>> The diff reports have
>> no equivalent of log's text-mods/props-mods but they do communicate that
>> a new node was created. The diff client could choose to output some
>> sort of "new node" message.
>
> (I assume you mean "new node-revision".)
More that the client could report some sort of "new version of file"
message.
> You have observed this
> correlation between new node-revs and editor method calls in the
> current typical Subversion software configuration. The client should
> not assume that an "open-dir" or "open-file" editor method call means
> a new node-revision in the file system. Node-revisions are meant to be
> a private implementation detail of the repos or FS layers.
The RA layer is public API. At present the RA layer invokes open_file
in the client's delta editor when there is a no-op text change so this
is a visible to the client. Our client chooses not to report this to
the user but other clients might choose differently. It's not entirely
clear what the client can assume about an open_file that is not followed
by either apply_textdelta or change_file_prop but it would not be
unreasonable for a client to report that it received open_file.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
Thanks for the additional examples of the inconsistencies, Philip and Daniel.
Daniel Shahaf wrote:
> Julian Foad wrote on Mon, Sep 22, 2014 at 09:43:22 +0100:
>> * You can't commit any no-op change using 'svn'.
>>
>> Except possibly for one or two remaining obscure bugs.
>
> This is one of them:
>
> [[[
> cp iota iota.bak
> echo "modified" > iota
> SVN_EDITOR='f(){ mv iota.bak iota; echo logmsg > $1; }; f' svn ci
> ]]]
Right -- I presume the client then commits a no-op change for file 'iota'. That's one effect of the way the client scans the WC first to determine the list of paths to be committed (no-change files are excluded, but 'iota' at this stage has a change), then waits to get a log message, then reads the WC again to calculate the actual change to send for each path (and now 'iota' has no change). This general behaviour affects more than just no-op changes, of course: if you apply a patch to several files while editing the log message, some of the patched files might be committed (those that were already modified at the invocation of the commit command) and others not.
Philip Martin wrote:
> Julian Foad writes:
>> [[[
>> $ svn diff --summarize -c6 $REPO
>> [no output]
>>
>> $ svn log -vq --xml -r6 $REPO
>> <... prop-mods="true">/trunk</path>
>> ]]]
>>
>> This output says that there was a property "modification" in r6
>> ... and yet shows no changes.
>
> The diff output is partly a choice made by the client itself. If we
> operate on a non-root node:
>
> svnadmin create repo
> svn mkdir -mm file://`pwd`/repo/A
> svnmucc -mm -U put repo/format file://`pwd`/repo/A/f
> svnmucc -mm -U put repo/format file://`pwd`/repo/A/f
> svnmucc -mm -U propel p file://`pwd`/repo/A
>
> The diff reports that the server sends to the client include an open-dir
> for /A in -c3 and an open-file for /A/f in -c4.
(I think you mean the other way around -- the open-file for /A/f is in -c3.)
> The diff reports have
> no equivalent of log's text-mods/props-mods but they do communicate that
> a new node was created. The diff client could choose to output some
> sort of "new node" message.
(I assume you mean "new node-revision".) You have observed this correlation between new node-revs and editor method calls in the current typical Subversion software configuration. The client should not assume that an "open-dir" or "open-file" editor method call means a new node-revision in the file system. Node-revisions are meant to be a private implementation detail of the repos or FS layers.
> 'svnlook changed' has behaviour that is somewhere between log and diff
> above: it indicates a change for for the text no-op -r3 but no change
> for the property no-op -r4.
Heh, nice observation.
- Julian
Re: No no-op changes
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@btopenworld.com> writes:
> [[[
> $ 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.
The diff output is partly a choice made by the client itself. If we
operate on a non-root node:
svnadmin create repo
svn mkdir -mm file://`pwd`/repo/A
svnmucc -mm -U put repo/format file://`pwd`/repo/A/f
svnmucc -mm -U put repo/format file://`pwd`/repo/A/f
svnmucc -mm -U propel p file://`pwd`/repo/A
The diff reports that the server sends to the client include an open-dir
for /A in -c3 and an open-file for /A/f in -c4. The diff reports have
no equivalent of log's text-mods/props-mods but they do communicate that
a new node was created. The diff client could choose to output some
sort of "new node" message.
'svnlook changed' has behaviour that is somewhere between log and diff
above: it indicates a change for for the text no-op -r3 but no change
for the property no-op -r4.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: No no-op changes
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Sep 22, 2014 at 1:40 PM, C. Michael Pilato <cm...@collab.net>
wrote:
> On 09/22/2014 12:13 PM, Julian Foad wrote:
> > Yup. So let's say we can agree to hide this behaviour at the repos
> layer. Then we face the decision of what to do with the FS layer:
> >
> > * make FS layer consistently version no-ops
> > -- a lot of work at FS layer
> > -- some work at repos layer
> >
> > * make FS layer consistently not version no-ops
> > -- some work at FS layer
> > -- no work at repos layer
> >
> > * leave FS layer as it is, partially implemented
> > -- no work at FS layer
> > -- some work at repos layer
> >
> > Which approach would you favour, and why?
>
> "make FS layer consistently not version no-ops" stands in opposition to
> the historical intent for the FS layer. The other two options are fine
> with me, though I confess that at this stage of the game, trying to
> retroactively consistify the FS layer's behavior without a driving
> use-case ...
Right. I've kind of lost the use-case this whole thread is suggesting we
"solve", and how the 14+ year behavior somehow interferes with that.
-g
Re: No no-op changes
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 09/22/2014 12:13 PM, Julian Foad wrote:
> Yup. So let's say we can agree to hide this behaviour at the repos layer. Then we face the decision of what to do with the FS layer:
>
> * make FS layer consistently version no-ops
> -- a lot of work at FS layer
> -- some work at repos layer
>
> * make FS layer consistently not version no-ops
> -- some work at FS layer
> -- no work at repos layer
>
> * leave FS layer as it is, partially implemented
> -- no work at FS layer
> -- some work at repos layer
>
> Which approach would you favour, and why?
"make FS layer consistently not version no-ops" stands in opposition to
the historical intent for the FS layer. The other two options are fine
with me, though I confess that at this stage of the game, trying to
retroactively consistify the FS layer's behavior without a driving
use-case beyond mere developer OCD seems like a waste of time of
energy. That said, it's neither my time nor energy at risk, so weigh my
input accordingly.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> On 09/22/2014 11:04 AM, Julian Foad wrote:
>> Would you accept that it now makes more sense to make the overall
>> system behaviour more consistent by moving towards the majority
>> direction (not preserving no-ops)? At least at some layers -- repos
>> layer or RA layer?
>
> "At least at some layers", yes, absolutely.
>
> In general, I favor consistency, but the scope of that consistency
> matters, [...]
Excellent. Thank you for clarifying.
> More to the topic, I continue to see value in preserving no-op
> operations in the FS layer. But at the client end of things, I would
> agree that the most users don't care to be bothered by such nuances. So
> as it does for others of those behaviors that differ at extreme ends of
> the Subversion system, some mitigation needs to take place somewhere in
> the middle. And that "somewhere" depends on what you want to permit.
Yup. So let's say we can agree to hide this behaviour at the repos layer. Then we face the decision of what to do with the FS layer:
* make FS layer consistently version no-ops
-- a lot of work at FS layer
-- some work at repos layer
* make FS layer consistently not version no-ops
-- some work at FS layer
-- no work at repos layer
* leave FS layer as it is, partially implemented
-- no work at FS layer
-- some work at repos layer
Which approach would you favour, and why?
> For example, if that mitigation happens at the repos layer, that's fine
> for the most part ... but what about the likes of 'svnrdump', which is
> trying its darnedest to act like a repos-layer dump/load driver but sits
> on the other end of the higher RA layer?
Anything working over the RA layer is subject to RA layer limitations -- this already applies in respect of authorization, for example. So no problem there.
- Julian
Re: No no-op changes
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 09/22/2014 11:04 AM, Julian Foad wrote:
> Would you accept that it now makes more sense to make the overall
> system behaviour more consistent by moving towards the majority
> direction (not preserving no-ops)? At least at some layers -- repos
> layer or RA layer?
"At least at some layers", yes, absolutely.
In general, I favor consistency, but the scope of that consistency
matters, especially in a modular system such as Subversion. For
example, I've always appreciated the idea that the Subversion FS layer
was designed with academic DAG-based version control theory in mind (not
mine, of course!), and as such will allow some things to happen that
perhaps we prefer to block from happening at levels of Subversion which
are closer to the end user. Some have argued that this should not be --
that the FS layer should enforce exactly what the client layer does. I
disagree.
More to the topic, I continue to see value in preserving no-op
operations in the FS layer. But at the client end of things, I would
agree that the most users don't care to be bothered by such nuances. So
as it does for others of those behaviors that differ at extreme ends of
the Subversion system, some mitigation needs to take place somewhere in
the middle. And that "somewhere" depends on what you want to permit.
For example, if that mitigation happens at the repos layer, that's fine
for the most part ... but what about the likes of 'svnrdump', which is
trying its darnedest to act like a repos-layer dump/load driver but sits
on the other end of the higher RA layer?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> On 09/20/2014 03:56 AM, Branko Čibej wrote:
>> We should do exactly the opposite! We should make sure that even no-op changes
>> always get recorded and reported consistently. [...]
>
> FWIW, this line of thought is consistent with the original FS
> backend and dump/load design goals. The guiding principle was about
> preserving as much information as we could rather than presuming
> that we knew what information did and didn't matter to an
> administrator.
Hi, C-Mike. Thank you for that bit of background context. To be clear, I take it that you are merely pointing out that there was a thought process that led to this present behaviour and it was not just a coding mistake. That's fine. It's good to know a bit about how the present state came to be.
> This is why svn_fs_props_changed() and
> svn_fs_contents_changed() never bothered to compare the respective
> prop/text content, but merely noticed that the DAG had or hadn't
> been adjusted.
That's as may be, but the undocumented behaviour of those two functions, and some records in the dump file output, seem to be the only trace that a "no-op change" concept ever existed. Neither of those functions is called directly by any test code, and their doc strings never hinted (until r1572363 this year) at any such intention. In fact, as far as I can see there is no mention of this concept in any of our documentation anywhere. Nothing describes what kind of committed "changes" might or might not be recorded as a change. Nothing describes what no-op edits an svn_delta_editor_t implementation must pass on. And as I mentioned elsethread this FS information is not preserved [1] by a dump and load.
In fact, as we have long tried to avoid committing no-op changes, we would never have encountered those use cases except if third parties were writing code directly against the low level APIs.
Would you accept that it now makes more sense to make the overall system behaviour more consistent by moving towards the majority direction (not preserving no-ops)? At least at some layers -- repos layer or RA layer? Or do you first need more information?
I want to get some agreement in principle before going on to discuss exactly what behaviours should be changed at what layers, with due consideration for backward compatibility of APIs etc.
- Julian
[1] I just noticed that different versions of Subversion do not all preserve the same set of no-op "change" evidence through dump and load.
Re: No no-op changes
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 09/20/2014 03:56 AM, Branko Čibej wrote:
> 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.
FWIW, this line of thought is consistent with the original FS backend
and dump/load design goals. The guiding principle was about preserving
as much information as we could rather than presuming that we knew what
information did and didn't matter to an administrator. This is why
svn_fs_props_changed() and svn_fs_contents_changed() never bothered to
compare the respective prop/text content, but merely noticed that the
DAG had or hadn't been adjusted.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Stein wrote:
> Branko Čibej wrote:
>> We should do exactly the opposite! We should make sure that even no-op changes
>> always get recorded and reported consistently. [...]
>
> Agreed.
Hi Greg.
> When you start including ACLs, then r1234 might look different to two people.
A revision can already look different to two people, with the existing path-based authorization mechanism.
> And if it gets elided because it "isn't a change", then one person is going to get
> even more confused when the revision doesn't even appear (rather than "no visible
> changes").
A revision will not get elided just because no changes are visible in it. I was talking about per-node changes. To quote again from my original mail,
"The ability to commit a new revision with no changes is fine -- a new revision number in Subversion does not imply a change."
Similarly, the ability to see or extract a revision with no (visible) changes is and will remain perfectly fine.
- Julian
Re: No no-op changes
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Sep 20, 2014 at 2:56 AM, Branko Čibej <br...@wandisco.com> wrote:
>...
> 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.
>
Agreed.
When you start including ACLs, then r1234 might look different to two
people. And if it gets elided because it "isn't a change", then one person
is going to get even more confused when the revision doesn't even appear
(rather than "no visible changes").
Cheers,
-g
Re: No no-op changes
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Mon, Sep 22, 2014 at 09:43:22 +0100:
> * You can't commit any no-op change using 'svn'.
>
> Except possibly for one or two remaining obscure bugs.
This is one of them:
[[[
cp iota iota.bak
echo "modified" > iota
SVN_EDITOR='f(){ mv iota.bak iota; echo logmsg > $1; }; f' svn ci
]]]
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> On 19.09.2014 16:49, Julian Foad wrote:
>> $ svn diff --summarize -c6 $REPO
>> [no output]
>> $ svn log -vq --xml -r6 $REPO
>> <... 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.
That's correct, and works correctly.
> * 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.
You're seizing on one of very few observable instances where Subversion notices a no-op change, and imagining a use case where the general case of recording no-op change attempts could be useful, and claiming therefore it's useful.
You're ignoring the fact that Subversion generally does NOT version "no-op" changes.
* The "no-op changes" in my example are not preserved through dump and load!
* You can't schedule a no-op change for commit in a working copy.
* You can't commit any no-op change using 'svn'.
Except possibly for one or two remaining obscure bugs.
> 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.
May I ask if you've thought this through? In a version control system that consistently versions no-op "changes", the user would have to be aware of the difference. When a user commits from the WC they would have to choose whether they mean "commit only the differences I've made" or "record all of the nodes I've touched as 'changed' by me". "Revert" could mean "mark this as no longer touched" or "revert the change but clearly I still have touched this". "Diff" and "patch" should be no-op-aware. "Merge" would need to have an option whether to merge no-op "changes", or we'd have to decide that it always should or always shouldn't. Need I go on?
Basically, it boils down to this: There is self-consistency in a system in which "change" means "difference". To invent a self-consistent system in which "change" does not imply "difference" would be to invent a very different version control system.
> 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.
That principle is correct, but it does not mean that we want to consider no-op changes as versioned changes. The appropriate kind of auditing for that is repository connection logs: the evidence that a particular user opened a commit transaction and wrote certain data to it and committed it.
- Julian
Re: No no-op changes
Posted by Branko Čibej <br...@wandisco.com>.
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
Re: No no-op changes
Posted by Julian Foad <ju...@btopenworld.com>.
Bert Huijben wrote:
[...]
> 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...
Actually it is a FS layer problem. svn_fs_paths_changed2() returns paths which have in fact not had a change. (I don't know if this is the only place where we get it wrong, but it is the most obvious one.)
> 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)
We should certainly not throw an error, if that's what you mean by "block".
We should allow a no-op "change" to be requested, and we should preferably store no change[1], and as a second-best option we could at least get the FS layer API right by reporting no "change" through the API, although this would still leave the on-disk storage non-canonical.
> And I'm not sure if we really solve something by ignoring them.
What we solve is the problems caused by inconsistency. At present (on the 'move-tracking-2' branch) I am trying to interpose 'shims' in the commit and update editors. The shim stores up the set of changes being driven into the editor interface and then re-plays those edits in a batch. It does not replay no-op changes; to do that I would have to write extra code to remember exactly what editor methods were called rather than just what the overall result was. And yet I get some test failures because some tests are written to expect the specific behaviour of the leaky abstraction that we have provided.
- Julian
[1] Again, to be clear, I don't mean no empty revisions, I'm talking about a change of properties or of text of a node.
RE: No no-op changes
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Julian Foad [mailto:julianfoad@btopenworld.com]
> Sent: vrijdag 19 september 2014 16:50
> To: dev@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