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.kot...@visualsvn.com> wrote: > Stefan Fuhrmann <stefan.fuhrm...@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 <jcor...@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
