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.)
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?
- 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
