Julian Foad wrote on Tue, Sep 22, 2015 at 12:54:58 +0200:
> Daniel Shahaf wrote:
> > Johan Corveleyn wrote:
> >> [...], revision N-1 contains a real
> >> change, but only a short log message; and revision N has a no-op
> >> change to that same path, and a very informative log message [...]
> >
> > The FreeBSD project used to intentionally make no-op commits (they term it
> > "forced commits") as part of their new committer workflow. I don't know
> > whether they still do that.
>
> We need to be careful with terminology. We're not talking about a
> no-op commit, we're talking about a path that is marked as 'changed'
> within a commit, but whose content did not change. (The same commit
> might or might not also contain other paths that have real changes.)
>
Yes, that is what I was referring to.
> In fact, I think one of the first things we need to do is a precise
> analysis of the issue:
>
> * What exactly are the existing possible forms of 'no-op change'
> that any part of Subversion can represent?
> - Text-change?
There's another hair to split here: a "no-op text change" can take two
forms: either an _empty_ delta — that is, an svndiff stream with no
windows — or a non-empty delta that, when applied to the source file,
produces the source file again.
The former is conceptually
--- iota
+++ iota
[no hunks]
The latter is conceptually
--- iota
+++ iota
@@ -1 +1 @@
-This is the file 'iota'.
+This is the file 'iota'.
(saying "conceptually" because text deltas are _not_ unidiffs)
Cheers,
Daniel
> - Props-change?
> - Whole-node-change?
> - Commit? (not so interesting in the current issue)
> - Only certain combinations of those?
>
> * At which APIs can each those changes be (a) made and (b) seen?
> - FS API?
> - Repos API?
> - RA and client-side APIs?
> - svnadmin dump/load?
> - svnrdump dump/load?
> - svnsync?
>
> - Julian
Received on 2015-09-23 15:08:03 CEST