On Tue, Sep 22, 2015 at 12:54 PM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> 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.)
OK, let's call that a null-text-change to that path. So, the path is
part of the changed paths, but has a null-text-change. Or something
like that?
> 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?
TBH, I'm not really interested in having a really fundamental
discussion about this (but feel free to drive that of course). What I
am interested in, is that we have a regression, and that 'dump' is
losing information (namely, not dumping correctly null-text-changes).
I think the dump.c part of r1572363 and r1573111 should be reverted /
fixed so that we get the previous behaviour again, and this should be
backported to 1.9. At this point, IMO 'svnadmin dump' is broken in
1.9.
Just one small addition on the fundamental part: I still think (like
we discussed during breakfast last Friday in Berlin :-)) there is no
problem in having / preserving / exposing null-text-changes to paths
in Subversion. I think we have to, for backwards compatibility, and I
see no problem in doing so. And to answer the last question you posed
me last Friday: the reverse diff of a null-text-changed-path is
identical to the forward diff: a diff with no changed lines :-).
--
Johan
Received on 2015-09-23 11:04:13 CEST