I think the problem with this issue is that it is not difficult to make a
compelling argument for either side. I have always been in favor of the
auto-upgrade, but I am now leaning the other way.
As I understand it, upgrading the repos is trivial. Say you have to run
svnadmin upgrade it is going to take 1 second. Where as a dump load could
easily take a day or more and the repos is down the whole time. Picture a
scenario where users are using a GUI like Subclipse or Tortoise. Once 1.2
is out, that will be the only version those products ship. It could be
fairly easy in both products for new users to take a lock option just to
see what it does. In a mixed version network that could then lock out
users from the repos. Granted, these people shouldn't be using file://
but that is another issue.
So I suppose my vote would be you have to run an svnadmin upgrade command,
and svnadmin create would create 1.1 repos format. Although, I would be
in favor of some kind of command line argument to svnadmin create to
create a 1.2 repos format.
If we decide to keep auto upgrading in as the default, how hard would it
be to create an svnadmin command to "downgrade" a repos? Perhaps that
would be a compromise? If a repos could be fixed in a couple of seconds
with one command, then maybe this would be less of an issue and we could
go back to considering this an edge case. But, I just do not think we
should create a dump/load scenario if it can be avoided.
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 19:11:45 2005