Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9

Bert Huijben <bert_at_qqmail.nl> writes:

> I'm just -0.9 on reverting the rest 'as it *may* have problems too'.

Perhaps I was not clear on my motivation, so here is how I see it.

We had state A, and it has been well-defined during many consecutive releases.
Then we made an arbitrary change that transitioned everything to state B. This
transition to state B doesn't fix any user-visible problems. One year later we
discover a couple of broken cases that affect users in concrete ways — and,
unfortunately, one of them was only noticed after we released 1.9.

What can we do about that?

(1) Get back to state A, as the change was arbitrary. We couldn't foresee
    the consequences of the change and that resulted in problems. The change
    itself didn't have a specific use case in mind and didn't target a specific
    user-visible problem. As opposed to that, state A existed for a long time,
    had a reasoning behind the chosen design, and everyone was happy with it.

(2) Move into state B* that mitigates the concrete problem for concrete users.

If you're thinking that we should do (2), this leaves some questions:

- Why is the arbitrary change made without a specific use case in mind suddenly
  more sacred than state A that has been working for years?

- Should we be fixing other problems possibly caused by this change in patch
  releases, as they happen to unveil themselves?

- What are the benefits from going to B* from the end-user's perspective?
  Perhaps, there are more important things that we could concentrate on,
  instead of possibly dealing with other problems caused by an arbitrary change
  in 1.9? Although this is particularly out of scope of this discussion, we
  are spending time on solving a problem that wasn't bothering anyone and
  probably didn't exist in the past.

> Yes, there are still more users that use 1.0-1.8.x, but that doesn't make
> the 1.9.0-1.9.2 behavior directly 'broken'... 1.8.x has different behavior,
> relying on unexpected/unintended features but for many users they are useful.

I hardly believe that the previous behavior that dates back to year 2001 is
less expected/intended than the behavior done by a commit that doesn't target
a specific use case and has as well broken several use cases.

Since this discussion has been lasting for over a month now, I proposed
what I believe is the proper solution for the problem (and that's (1) )
in /branches/1.9.x/STATUS.

Regards,
Evgeny Kotkov
Received on 2015-10-29 14:50:33 CET