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. >> 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. >> 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 :-). > > There is no problem with recording such changes, but the real question > is whether they have any useful semantics. Backwards compatibility does > not mean hanging on to every silly decision we've ever made as if our > (or our users') lives depended on it. > > > We've already made (IMO) more questionable changes; for example, > forbidding control characters in file names was in no small way driven > by the fact that our dump format can't represent them. So instead of > fixing the dump format we decided to break old repositories. That's a > far more serious change than dropping no-op node changes from the dump file. Okay, but in that case we did that for a clear reason: it broke the dump format. What would be the compelling reason here to break backward compatibility and possibly break some people's use of the repository history? -- Johan
