> 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.
Not that it matters, but I agree with Ben and think the current approach is
best. Once 1.2 is GA, this scenario you describe seems like an edge case
at best. You could certainly just as easily make the argument that having
a whole lot of people try to lock something only to have it fail is going
to cause just as much problem if not more.
I think the other item that was brought up (if 1.2 does not auto-upgrade
the repository) was that you would still have the issue of what should
svnadmin create do in 1.2? If it creates the new format repository then
you could just as easily create the scenario you describe, but it seems
crazy that a new 1.2 user should have to run svnadmin create AND svnadmin
upgrade in order to use locking.
In this scenario, both choices have good and bad elements to them. I just
think the current design has more in its favor than the alternative.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 26 02:13:57 2005