I'd like to apologize for dropping such a bikesheddy issue on us with
rc5 impending. This only caught my attention today, as I was doing the
format bump change.
I have renamed --no-svndiff1 to --pre-1.4-compatible. My rationale is:
The average repository administrator will have no intuitive
understanding of "no-svndiff1" - it has meaning only to Subversion
developers. Exposing the codename of an internal data format in our
public UI is definitely not a good UI design. On the other hand, I think
"pre-1.4-compatible", whilst a little verbose, conveys the meaning
without sending an average svn admin off to do research.
Furthermore, the "no-<feature>" naming scheme engenders a potential
misunderstanding in the nature of both the command line flag and the
underlying API: it encourages thought of it as an independently
toggle-able option, rather than a selection of versions from a linear
sequence. I realized this potential after Malcolm provided me with some
fresh perspective on IRC, by conjecturing the potential desire to
combine some other future change brought a further repository format
bump, with the absence of svndiff1 - for example, because of a desire to
avoid zlib. Under these circumstances, you could end up with two flags
with feature-based names, which would actually have non-obvious
inter-dependencies, since the two yes/no choices would need to map down
to actual version numbers. Phrasing these choices in terms of version
numbers instead makes it clearly obvious to users what the results of
using them are, and approaches the topic from the angle of most
importance to many: "will this repository work with the versions I need
it to?", not "what underlying technologies/algorithms are in use?".
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.
Max.
Received on Wed Aug 23 00:01:19 2006