[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 23 Sep 2015 11:55:28 +0100

> Johan Corveleyn wrote:
>> [...] 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.

1. I pretty much agree now that we should revert the change.

We understand now that the change in 1.9.0 was unintentional, and
after we analyse the situation, we are very unlikely to conclude that
that change was a complete bug fix to the whole issue of no-op
changes. It is surprising and is regarded as losing information, and
is not justified (yet) by some higher purpose.

It seems fairly clear what the change was, and so how to revert it.

2. We might also want to make another change to the behaviour of
'svnadmin load', so that the result of loading a dump file that people
have *already* produced using 1.9.0-1.9.2 will be the same as if they
had dumped and loaded using 1.8.x. I don't yet understand the details
enough to know whether this option is possible.

3. I firmly believe that our handling of 'no-op changes' is mistaken
and a bad idea. I'll explain that, but not in this thread -- that's a
follow-on task.

Brane wrote:
> I also suggest adding a note to
> http://subversion.apache.org/docs/release-notes/1.9.html#issues .

And we need to file an issue.

I'll do both of those things (issue and rel-notes) now.

- Julian
Received on 2015-09-23 13:03:21 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.