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
