[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 17:36:15 CEST

Daniel Berlin wrote:
>> You've countered by saying "no, you're wrong, this is really better",
>> 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 agree wholeheartedly with this.

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.

> I introduced the flag with a name that made it clear what it did, with
> the expectation that the small number who needed it would figure out
> that they needed it when SVN reported an error message about the svndiff
> version being too new.
> To wit:
> "Oh, it says this repository has an unexpected svndiff version in it, I
> probably needed to create this repository with that crazy --no-svndiff1
> flag!"

OK, the name made more sense with that underlying assumption, but the
error message will be about a format mismatch, and does not mention
svndiff1. Also I think I remember Malcolm reporting that the error
message did not mention svndiff even before the format bump, instead
being something similar to "invalid insn, cannot decode diff stream".

> I honestly don't care what we name it (though i believe the new name is
> actually worse for users for much the same reasons as the other
> dissenters),

Could you explain your reasons, please?

The other dissenters are:
  to whom I responded explaining why I don't think the reasons
  were valid.
  who is neutral on the choice of name, and only finds the
  timescale to be the problem.
  who had not posted objections to the name until after you wrote
  the above.

> however, i am disappointed in the way this email discussion
> has gone.
> However, I honestly expected better than to see the typical (in bikeshed
> discussions) response that contained a list of:
> 1. "people i think agree with me"
> 2. "people whose emails i can kinda claim have no real opinion, but if
> you look close, really disagreed with me, even if for other reasons ",
> 3. "people who disagreed with me but who i think are wrong, and i've
> told them they are wrong, so that's that".

Since I was declining Garrett's request to revert, I felt I was obliged
to assess the spectrum of opinions presented so far in justification of
that, hence the list.

In point 2., you say that I have misstated the emails of others. I have
gone back and re-read all the emails sent before the one of mine to
which you refer, and I do not think I behaved as you say.

In point 3., "i've told them they are wrong, so that's that" is not
true. I provided reasons for my disagreement, and nowhere did I refuse
to listen to further comments.

> This is not the way to happiness.
> IMHO, A reasonable compromise position in this case would have been to
> just make the flag work with *both* names, and in the help text, note
> that one is just an alias for the other..
> It's not like we are running out of long option names for svnadmin create.

That would, I think, be the worst of both worlds, since most of my
objections are regarding 'no svndiff1' being an undesirable choice of
terminology itself, whilst also adding a new option would be more code
churn than a rename.

> In any case, this change isn't, and wasn't, important enough to hold up
> a release for.

I believe it has importance as it sets precedent for handling future
repository format bumps in the 1.x era.

> In the GCC world, at some point, the release branch
> becomes "regression fix only" (it eventually becomes bug-fix only again
> after release, for the next minor release). This means even *regular*
> bug fixes cannot be applied, only those that are regressions from
> previous versions[1].

We could potentially choose to adopt such a policy, but except for this
one present issue, informal decisions of whether a change is too big
have served us well.

> I also don't believe that we should care so much about compatability
> that if we wanted to rename a long option name for something pretty much
> unused, in svnadmin create, that this would be verbotten until 2.0.

In absence of actual documented rules, we've thus far assumed absolute
strictness except where unavoidable.

> [1] The first one to argue that a new option, "badly named", is a
> regression from a previous version is going to be publicly flogged.

*ahem* Actually, I think that logic has quite a bit of credibility :-)


Received on Thu Aug 24 17:40:42 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.