subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9
Date Wed, 23 Sep 2015 10:09:22 GMT
On 23.09.2015 11:58, Johan Corveleyn wrote:
> On Wed, Sep 23, 2015 at 11:44 AM, Branko ─îibej <brane@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.

Hearsay! :)

>>> 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.
>> 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
http://subversion.apache.org/docs/release-notes/1.9.html#issues .

-- Brane


Mime
View raw message