Re: locking a file renders repos unusable with older clients

Ben Collins-Sussman schrieb:

> Is it worse for 5 admins to have to dump & load when they decide to
> downgrade?
> Or is it worse for 10,000 admins to run 'svnadmin upgrade' to enable locks?

Just my personal opinion on this:

You should look at this issue from a different perspective:

I am tempted think in most cases where network admins are involved
subversion runs on apache or svnserve. On these systems you need to
upgrade the server and then the repository manually to enable locking.
No auto-update here. So 9,500 of the 10,000 admins need to do some
manual work anyway.

But when using subversion on a network share with file:// access (which
is allowed with fsfs, isn't it?) then one person just trying svn 1.2
once might accidentally upgrade the repos and cause problems to all
other members in the team.

I believe enabling locking for a repository (that includes repository
upgrade) should be a concious decision of the development team using
subversion. And the team should have a chance to decide when to upgrade.
There is no auto-update for http: and svn: access methods, and there
should be none for file: access. Only then the point of upgrade can be
postponed until all clients have been upgraded.

The case where automatic update might be ok is when file: access is used
on the local computer. And this is a case where locking might not be
that important.

Ok, just my personal thoughts...

Norbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 26 13:12:29 2005