>
> 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 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!"
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), 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".
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.
In any case, this change isn't, and wasn't, important enough to hold up
a release for.
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].
IMHO, 1.4's branch should be like that at this point, and this change
shouldn't even be considered for it.
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.
--Dan
[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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 23 16:46:28 2006