[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: locking a file renders repos unusable with older clients

From: Norbert Unterberg <nepo_at_gmx.net>
Date: 2005-03-26 15:48:14 CET

Ben Collins-Sussman schrieb:

> Norbert Unterberg wrote:
>
>>> I do not think this is true. I believe the repository will auto-update
>>> regardless of the RA method used to access it.
>>>
>>>
>> I do not know that much details about subversion, but I did not think
>> that a subversion 1.1 svnserve process or mod_ dav_svn module
>> running on a server would upgrade the repository to a 1.2 format when
>> processing requests from a remote 1.2 client?
>
>
> Any program that links to libsvn_repos 1.2, and then opens a
> repository, will auto-upgrade the repository's 'format' file. This
> could be an svn 1.2 client using file:///, or it could be *any*
> version of mod_dav_svn or svnserve that just happens to link to the
> libsvn 1.2 libraries.
>
Yes, that was my point (I think I did not make it clear enough): To
upgrade a repository that is handled by mod_dav_svn or svnserve, the
admin needs to upgrade the server applications to 1.2. When a user
upgrades just his client to 1.2, then the server remains at 1.1 and the
repository does not auto-upgrade. That means the upgrade is a conscious
decision and does not happen accidentally. If a repository is run with
file:// access on a shared network drive then the upgrade can
*acidentally* happen just by one of the users evaluating or trying the
new client.

In addition, upgrading a mod_dav_svn or svnserve server to version 1.2
is already an administrative task, so even the auto-upgrade mechanism
would not save the admins from doing work on their servers (I admit it
would save them the work of upgrading every single repository on a
multi-repos setup).

That's why I was pleading against auto-upgrade, at least for the file://
access method.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 26 15:49:33 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.