[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: r21207 (Renaming --no-svndiff1 to --pre-1.4-compatible)

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2006-08-24 14:44:22 CEST

Garrett Rooney wrote:
> On 8/23/06, Max Bowsher <maxb1@ukf.net> wrote:
>> Garrett Rooney wrote:
>> > On 8/22/06, Max Bowsher <maxb1@ukf.net> wrote:
>> >
>> >> Once again, sorry for broaching such bikesheddy issue. I'm sorely
>> >> concious that if I hadn't noticed that, we might have a RC5 within
>> a few
>> >> hours, but having noticed it, I could not in good conscience not take
>> >> action to correct what I believe was a severe UI and API wart.
>> >
>> > Oh please, you're dramatically overstating the importance of this
>> > change. The flag may be obscure, but its use case is also obscure,
>> > there's no reason we should be wasting anyone's time on it when the
>> > vast majority of users will never even need to know of its existence.
>> It's a wart. Wart's aren't fatal, but they don't help anyone's
>> impressions of Subversion. Since this is something that we are locked
>> in to for 1.x once we release, I feel it had to be brought up, and it
>> had to be brought up now.
>> > This is 100% a bikeshed issue, and there is zero reason to bring it up
>> > at this point in the release cycle. We have enough trouble fixing
>> > actual problems, there's no reason to actively go looking for
>> > pointless ones.
>> That's the thing: *why* is it a bikeshed issue? It's a simple, dare I
>> say trivial, renaming operation, for which I have explained the
>> rationale. I hoped, and continue to do so, that people will recognize it
>> as such: a trivial fix for some poorly-chosed terminology.
> It's a bikeshed issue because it has to do with the UI and there are
> at least two sets of opinions on the right way to do it.

Then we should examine the concrete advantages and come to a decision,
not avoid the issue.

> Additionally
> it's about something incredibly trivial, which always helps to fan the
> flames. You think it's a trivial fix because you happen to disagree
> with the way it was done. Other people will think you're wrong. None
> of it really matters because we're talking about a flag that almost
> nobody will ever use.

Even if it doesn't get much use, it is implicitly the foundation of the
UI and API with which we will handle control of versions of repository
formats throughout the 1.x era. As such, it is non-trivial in its
importance, though trivial in the sense that it is 'just' a renaming.

> It's one thing to say "we shouldn't hold off a meaningful change
> because we're about to do a release" and quite another to say "we
> should stop a release any time anyone has a trivial problem they'd
> like to address". I think we're firmly in category B here. It's like
> calling "stop the presses" at a major newspaper because there's a typo
> on page 6. Sure, you can fix the problem given the time, but
> honestly, who cares. (Yes, I agree this doesn't have the same cost as
> a "stop the presses" kind of thing, but there is still a cost in time
> we all spend trying to get this release out the door.)

There's a fuzzy line to be drawn here, and deciding which side of it
this problem lies on is a substantial fraction of this controversy. I
think it is important enough, because it's setting precedent for
handling format bumps in the future.

>> The reactions of committers so far have been:
>> You and Justin: Irked by the delay, but not commenting on the change
>> itself.
> I have commented on the change itself, I think it's 6 of 1/half dozen
> of the other. The change doesn't matter. Virtually no user will ever
> even use this option, so any time we spend arguing about it in EITHER
> DIRECTION is wasted. We could call it --paint-it-pink and it would
> only be marginally worse than it is now because despite the fact that
> users would have zero way to tell what it does from the name it still
> wouldn't matter because the vast majority of them still wouldn't ever
> need to care about this functionality.

Apologies, I confused no opinion and neutral opinion.

>> David James: Expressed tentative positive reaction, on reading my email.
>> Brane: Expressed misgivings, to which I responded with counter-arguments
>> which, IMO, dispel them.
>> That's not an adequate weight of opinion to recommend reverting as a
>> course of action to me - not when the sole negative reaction against the
>> change (rather than its timing) is one that I think I have suitably
>> logically countered.
> You've countered by saying "no, you're wrong, this is really better",

I felt I was presenting logical reasons, and am a little miffed that you
characterize them so. Please at least explain *why* you find my
reasoning to be at fault.

> and since this is a UI thing with no clear answer Brane can just as
> reasonably respond with "no, I disagree, you're wrong". There is no
> way to win this argument in a reasonable amount of time.

I don't want to win it. I want to reach a mutually acceptable
conclusion, and happen to think that my viewpoint has sufficient
supporting factual grounds to make it a serious possible outcome.


Received on Thu Aug 24 15:04:23 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.