subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@btopenworld.com>
Subject Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9
Date Wed, 14 Oct 2015 16:53:09 GMT
All,

Please see the email I've just sent, entitled "Changes, Differences,
and States". I wanted to put down some thoughts and that's the best I
can do in the time. I hope it may shed a few glimmers of light in this
area.

- Julian


On 14 October 2015 at 16:37, Evgeny Kotkov <evgeny.kotkov@visualsvn.com> wrote:
> Stefan Fuhrmann <stefan.fuhrmann@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
>    committed.
>
>  - 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@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.
>
> Thoughts?
>
> [1] https://svn.apache.org/r1568600
>
>
> Regards,
> Evgeny Kotkov

Mime
View raw message