On Mar 25, 2005, at 5:20 PM, Max Bowsher wrote:
>
> But the above misses the point of the complaint.
Actually, I talked to Eric in IRC. The point of his complaint was only
that he wanted a warning, and would have been happier if the release
notes had warned. He understands that we don't want older clients
using file:/// to ignore locks created by newer clients.
>
> Whilst I do acknowledge that the "fine print" of our compatibility
> rules do allow current trunk behaviour, we've pushed quite hard the
> concept of "no dump/loads until 2.0". Allowing someone to accidentally
> cause their repository to be incompatibly upgraded is a very bad user
> experience, regardless of how big a notice we place in readmes/release
> notes.
How about all those times we silently upgraded the wc format?
>
> I would like to switch to performing repository upgrades *only* on an
> explicit "svnadmin upgrade" (the locking functions would return errors
> when running on a non-upgraded repository).
>
I thought you and Karl and others had already discussed this...?
While I agree that the scenario described by Eric is a "bad user
experience", I argue that it's also quite rare -- the rarity comes from
(1) the use of file:/// and (2) the probablilty of downgrading after
upgrading.
Meanwhile, balance that option against the "bad user experience" of
forcing every admin in the universe to run 'svnadmin upgrade' when they
move to 1.2.
Doesn't the former option seem more friendly to the world? Less hassle
to fewer people?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 26 00:40:25 2005