subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Subversion semantics: no no-op changes
Date Fri, 11 Oct 2019 18:23:18 GMT
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().

Mime
View raw message