[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion semantics: no no-op changes

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 11 Oct 2019 18:23:18 +0000

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?



¹ [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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.