有什么办法可以降低Subversion信息库的格式，从而避免出现以下消息：

svn: Expected format '3' of repository; found format '5'

当我们从多台计算机访问存储库，并且无法在所有这些计算机上使用一致版本的Subversion时，就会发生这种情况。

更糟糕的是，在不同的服务器上有多个具有不同格式的存储库，我不愿意升级其中一些服务器。

## 解决方案

### 

我怀疑我们必须导出存储库，然后将其重新导入到旧版本中。虽然导出格式可能存在一些格式不兼容的问题，但是由于它只是一个很大的文本文件，因此希望将它们剥离掉不会太困难。

### 

根据Subversion的书，这是没有办法的。我们必须导出整个存储库，然后在启动并运行较旧的版本后继续重新导入它。

无论如何，我建议我们在客户端计算机上相应地升级SVN工具，而不要在存储库中玩危险的游戏。

确定版本，在准备好升级到较新版本之前，请勿触摸它。

### 

如果不能在所有计算机上使用相同版本的Subversion，则应设置服务器进程(svnserve或者Apache)并仅通过服务器访问存储库。服务器可以在不同版本的Subversion之间进行调解。只有在使用直接存储库访问时，才会遇到此问题。

如果服务器将是比当前存储库格式更旧的版本(我不建议这样做)，则需要使用较新的版本导出存储库，并使用较旧的版本导入它。

### 

svnbook这样说(关于file：///访问与设置服务器)

``` java
Do not be seduced by the simple idea
  of having all of your users access a
  repository directly via file:// URLs.
  Even if the repository is readily
  available to everyone via a network
  share, this is a bad idea. It removes
  any layers of protection between the
  users and the repository: users can
  accidentally (or intentionally)
  corrupt the repository database, it
  becomes hard to take the repository
  offline for inspection or upgrade, and
  it can lead to a mess of file
  permission problems (see the section
  called “Supporting Multiple Repository
  Access Methods”). Note that this is
  also one of the reasons we warn
  against accessing repositories via
  svn+ssh:// URLs—from a security
  standpoint, it's effectively the same
  as local users accessing via file://,
  and it can entail all the same
  problems if the administrator isn't
  careful.
```

Subversion保证任何1.X客户端都可以与任何1.X服务器通信。通过使用服务器，我们可以一次升级服务器，并且客户端独立于服务器。