On 29.10.2015 17:13, Evgeny Kotkov wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>
>> If the state has been "well defined", then please point us to the
>> definition of it, or to the tests that confirm it works as defined. If
>> you can't, then the state has not been "well defined". All we can say
>> is it has been "unchanged" over a long period of time.
> Okay, the term 'well defined' might be not fully applicable here. But in the
> meanwhile, if we are looking for a proper term, saying that it's 'unchanged'
> is not enough as well.
>
> We had this unchanged state for many years and releases, and it wasn't causing
> practical problems for the users. The callers were relying on that behavior,
> and changing it caused several problems. On the contrary, I think that the
> r1572363 + r1573111 change we're talking about is 'undefined'. Using the
> same logic, could you please point to the tests that specify the behavior
> after this change?
The fact that we used to expose no-op changes in dumps and logs is
purely an accidental side-effect of the top-down DAG we happened to
chose for the repository structure. In other words, we've been exposing
FS implementation details to public API consumers. This was a mistake,
and the bug was fixed in 1.9.
> My point is that even if state A is not 'well defined', it's still better than
> the current 'undefined' state. It has been there for years, it wasn't causing
> problems, it had a reasoning behind it [1], and the callers were used to it.
The link you post to basically admits that we're using an API that deals
with details of the FS representation instead of the semantics of a
revision. We've never /defined/ the semantics; the current behaviour
that actually treats a no-op as a no-op is, IMO, quite a bit more
logical than the old behaviour.
-- Brane
-- Brane
Received on 2015-10-29 21:51:56 CET