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

Re: svn commit: r21209 - branches/1.4.x

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2006-08-23 11:02:05 CEST

Branko Čibej wrote:
>
> I think this renaming is wrong anyway. Whenever there's a potential
> compatibility issue, we always do feature tests, not version tests.
> That's true of the autoconf stuff (mostly ...), protocol negotiation,
> etc. etc. So --no-svndiff1 is actually more correct in this respect,
> even though it may look slightly more confusing to the user.

I feel that the above reasoning is logically flawed: you cannot take a
best-practice tenet about how build-systems should adapt to platform
incompatibilities, and apply it to UI design. The two fields are
scarcely related - that feature tests are appropriate for one does not
infer that they are appropriate to the other.

A vital quality of a UI is understandability for the user. Therefore, if
 --no-svndiff1 is more confusing that the alternative, it is not correct.

> For example, --pre-1.4-compatible could well mean "don't create BDB
> repositories if you're linked with BDB-4.4".

The above is not sensible: the BDB version is in no way intrinsic to the
Subversion version. You could just as well have a Subversion 1.3 linked
to BDB 4.2 and a Subversion 1.4 linked to BDB 4.3, producing a
compatibility barrier even though BDB 4.4 is not involved.

> It's not as obviously mnemonic as you think.

It's pretty obvious, and more obvious than --no-svndiff1, I think.

Thankyou for your comments, but it sounds to me that your objections
stem more from frustration at another release delay than with the
details of the change itself. I sympathize - I feel annoyed by the delay
too, but having noticed this issue, it couldn't in good conscience
pretend to forget about it, deliberately lowering the release quality to
get it out faster.

Max.

Received on Wed Aug 23 11:02:54 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.