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
>> 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
Received on 2015-09-23 11:58:58 CEST