Re: No no-op changes
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 22 Sep 2014 09:43:22 +0100
Branko Čibej wrote:
That's correct, and works correctly.
> * Log, on the other hand, displays an audit trail.
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,
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
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.
This is an archived mail posted to the Subversion Dev mailing list.