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_at_N+1 has copyfrom=bar_at_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().
Received on 2019-10-11 20:23:35 CEST