David James wrote:
> On 8/23/06, Daniel Berlin <dberlin@spork.dreamhost.com> wrote:
>> 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..
>
> +1. If the help text states that --no-svndiff1 is an alias for
> --pre-1.4-compatible, it'll be clear that the two concepts are one and
> the same. This solution makes the effect of the flag clear (i.e. it
> makes your repository compatible with Subversion 1.3 and earlier by
> disabling svndiff1). Obviously a flag which disables svndiff1 will not
> automatically make BDB 4.4 and/or FSFS compatible with Subversion 1.0.
I still don't like the idea of unnecessarily exposing the name 'svndiff'
in the UI at all. A regular user-administrator of Subversion should not
ever need to encounter the names of internal algorithms used. It is
another case of leakage of internal concepts out to the user, which we
already suffer from in our error messages, and which contributes to
Subversion being daunting to the less highly technical audience.
"--no-svndiff1" has never been in a release, so the only reason for
wanting it is on its own merits as a UI. Daniel Berlin made a good point
about it being good for mental correlation if the admins were being
confronted with error messages mentioning 'svndiff', but certainly since
the repository format bump, that will not be the visible failure mode at
all.
Max.
Received on Sat Aug 26 18:34:12 2006