On 23.09.2015 11:58, Johan Corveleyn wrote:
> On Wed, Sep 23, 2015 at 11:44 AM, Branko Čibej <brane_at_apache.org> wrote:
>> On 23.09.2015 11:03, Johan Corveleyn wrote:
>>> 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).
>> Well, without a "really fundamental" discussion you can't really decide
>> if it's a regression or a bug fix.
> Yes I can, because stefan2 told me in person that that part of the
> change in r1572363 was unintentional :-). IIUC, he didn't realize that
> it would have this effect on the output of dump.
>>> 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
>> What we really should determine is whether recording no-op node changes
>> in the repository was intentional or just an unfortunate site-effect of
>> something or other. I'm leaning towards the latter, which would make the
>> 1.9 change in 'svnadmin dump' a bugfix.
>> The point is that Subversion is supposed to track changes to a tree of
>> nodes (directories and files). Unlike empty revisions, no-op changes
>> have no useful value for either working copies or repository history.
> For repository history they do have useful value: the revision's log
> message might be very valuable, and now it's "attached" to that path's
> history (i.e. it's returned by 'svn log path'). By dropping the
> null-text-change, we drop the log message from that path's history.
> The relation between the log message and that particular path might be
> valuable / useful to someone.
See, we're already having a really fundamental discussion about what it
all means. Your point about log messages is well made. I hadn't thought
about that aspect.
Since you're a committer ... go ahead and make the fix and propose the
backport. I'm sure people will complain if they don't like it.
I also suggest adding a note to
Received on 2015-09-23 12:09:28 CEST