Ben Collins-Sussman wrote:
> 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?
Never since 1.0.
>> 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...?
But never reached a conclusion.
> 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?
I don't understand how the need to run one single quick command can be
described as "hassle".
I think it's simply the polite thing to do to let admins explicitly choose
when to upgrade.
Whereas, the sudden and unplanned need to dump/load to downgrade is a whole
lot of hassle.
Max.
---------------------------------------------------------------------
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:56:38 2005