[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: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Wed, 14 Oct 2015 18:37:01 +0300

Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:

>> Exactly how does this change make the situation better in practice? In
>> other words, what particular use cases is it supposed to fix?
> Any use-case that depends on this information, IOW all those that you
> are afraid may have been broken by the new API.


> * non-bubble-up directory representations, e.g. Brane's approach
> * "native" support for move / rename possibly not creating a new ID
> I'm not saying that any of these will be implemented in the near future
> but those ideas and proposals demonstrate that we cannot assume specifics
> of the DAG implementation.

So, this change doesn't improve any real use cases in the current code?

Overall, I don't see how it's worth it, as there were no user-visible problems
associated with the old code. The new approach, on the contrary, has a history
of breaking at least two use cases, and there could be more:

 - We were lucky to find and fix svn blame -g a year after the change was

 - Now, a year and a half later, we have an issue with repositories behaving
   differently in client-side operations like 'svn log' after dump/load. As
   the dump/load is a well-known procedure, I am thinking that it's a serious
   problem that could affect many users.

 - This could only be a part of the problems we need to deal with, because
   the low level behavior change from r1572363 + r1573111 propagates up to
   higher levels like svn_repos or svn_ra and alters the behavior of many
   different callers like svn_ra_get_file_revs2() or the update reporter.
   Third-party API callers could not be ready for it as well, because public
   API functions like svn_ra_get_file_revs2() didn't receive the erratum or
   a bump.

Johan Corveleyn <jcorvel_at_gmail.com> writes:

> 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.

I would like to commit the patch that restores 1.8 behavior in all relevant
places. It fixes the svnadmin dump issue and should prevent other similar
problems; see the attachment.

Please note that the patch doesn't do something about our experimental FSX
back end. As it turns out, the behavior of the svn_fs_contents_changed() and
svn_fs_props_changed() in FSX received a change even prior to the introduction
of the new API, and happened in r1568600 [1]. Although we could restore the
previous behavior for it, I am thinking that we should begin from fixing the
problem for the stable FSFS and BDB back ends.


[1] https://svn.apache.org/r1568600

Evgeny Kotkov

Received on 2015-10-14 17:37:38 CEST

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