Julian Foad wrote on Fri, Oct 11, 2019 at 15:56:31 +0100: > Hello Eric. Not to preëmpt Eric, but may I share my thoughts too?
> In conclusion, I consider svn would be a better system -- more predictable, > testable, composable, etc.; more generally dependable -- and would lose no > significant value at all -- if we were to explicitly remove no-op changes. > > Does this all ring true and obvious to you, or can you explain better what I > am getting at and what I'm missing? What layer do you want to forbid no-op changes at? At the FS level, a filesystem is an array of trees. The contents of rN place some restrictions on what the contents of rN+1 may be: for example, if foo@N+1 has copyfrom=bar@N, then foo and bar have the same node kind. At this level, I don't see a reason to forbid two successive trees from being equal.¹ The question isn't whether that's a _useful_ thing to do, but whether it has a consistent, well-defined semantics — to which, IMO, the answer is in the affirmative. That, incidentally, is also the reason why «x + 0» is a well-formed arithmetic expression. In C, it's perfectly valid to write «if (0) abort();», or even «foo; ;». It is not a syntax error. It _will_ generate a compiler warning, but you will be able to compile and run it. Similarly, I suspect "no no-op changes" is a semantic that belongs at the same level as "no mixed-revision or switched subtrees": it is something a user _usually_ don't want to do, but ultimately, it's their data, not ours. That's what we do in 'svn merge', which does that sanity check but makes it opt-outable. It's actually what we already do with empty revisions: 'svn commit' won't create an empty revision, but it _is_ possible to do so if one really wants to. Use-case: Imagine a company that is regulatorily required to review its foobar policy once a year. For that company, it would make perfect sense to create a commit that _doesn't_ change the contents of the policy, but does mark the file as changed (in «svn log -qv», etc), with the log message "Policy reviewed and reaffirmed without changes.". Yes, it's a metadata-only change. Makes sense? Cheers, Daniel ¹ [Hair splitting: when I say "equal" I mean, "equal as far as a consumer of the replay or dump API can detect. That is, node-rev-id's are not available to distinguish wish.] P.S. Relevant APIs: svn_fs_contents_different() v. svn_fs_contents_changed().
