On 23.09.2015 11:58, Johan Corveleyn wrote: > On Wed, Sep 23, 2015 at 11:44 AM, Branko Čibej <br...@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