On Thu, Oct 8, 2015 at 1:07 PM, Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
wrote:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>
> > This is not about performance, it is about API guarantees and functional
> > stability. So, yes that is an optimization in the sense of "making it
> better
> > than before". And no, we should not go back to worse unless there is no
> other
> > practical way.
>
> 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.
Decoupling API behaviour from implementation details is
about preventing future breakage in the callers of that API.
Two proposed backend changes come to my mind that
may affect the conditions under which new noderevs will
be created:
* 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.
> I see it as an abstract change that alters the behavior of many different
> calling sites. Given that the practical benefits are unknown, I think that
> we should restore the known stable behavior, and avoid problems coming
> from various places.
>
As shown above, the behaviour is not know stable. In fact,
SVN 1.5 had to jump through loops to mimic the original
behaviour by adding "uniquifiers" to shared representations.
If it was a mere theoretical issue, I wouldn't have bothered
addressing it.
-- Stefan^2.
Received on 2015-10-11 14:21:30 CEST