On Wed, Oct 14, 2015 at 6:53 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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.
Thanks, Julian, that's a great effort. I've quickly read through it,
and the concept of "touched" vs. "modified" (also mentioned by stefan2
earlier in this thread) sounds interesting. As well as the fact that
no-op changes may be relevant for "single state transitions" (such as
reported by log -v, or when dumping), but not interesting /
well-defined when comparing between artibitrary points in history.
That resonates well with me.
> On 14 October 2015 at 16:37, Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com> wrote:
>> 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
>> 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_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.
>>
>> Thoughts?
>>
>> [1] https://svn.apache.org/r1568600
>>
>>
>> Regards,
>> Evgeny Kotkov
I don't know if a full revert, or a forward-working fix is the best
course of action. The immediate concern for me is fixing the
regression of losing no-op change information in dumps. Perhaps if
stefan2's work can be fitted in the larger picture of a design such as
Julian's (and then fix the bugs from that perspective), that might be
the best way forward. Or perhaps this is too risky to do in a short
time frame (since we already have the bug in released versions), and
it's best to rollback and perform the "rework" with a proper design
for 1.10 (so there is more time to stabilize design and
implementation)? Dunno.
Would the rollback reintroduce old bugs or unpredictable behavior that
we know of?
--
Johan
Received on 2015-10-15 13:39:59 CEST