我阅读了发布说明
旧版本的客户端和服务器可以与1.7版本的服务器和客户端无缝配合工作。但是,除非客户端和服务器都是最新版本,否则某些新的1.7功能可能无法使用。此外,在客户端是新版本而服务器是旧版本的情况下,某些新功能虽然可以运行,但效率可能会降低。
不需要导出并重新载入存储库。Subversion 1.7服务器可以读写由早期版本创建的存储库。要升级现有的服务器安装,只需在旧版本上安装最新的库和二进制文件即可。
Subversion 1.7服务器使用与Subversion 1.6相同的存储库格式。因此,可以在不更改磁盘上存储库的格式的情况下,无缝升级和降级到1.6.x和1.7.x服务器之间(对于任何一对1.x和1.y服务器来说,这通常是不正确的,但对于1.6和1.7是成立的)。如果在服务器上启用了新的1.7功能(在钩子或服务器配置文件中),当回滚到1.6服务器之前,它们当然必须被禁用。
Subversion 1.7客户端使用新的工作副本格式。Subversion 1.7客户端无法使用Subversion 1.6(及更早版本)的工作副本。必须先升级使用Subversion 1.6和更早版本创建的现有工作副本,才能使用Subversion 1.7客户端。
如果我没记错的话,1.5版本也可以自动升级到1.6版。
Subversion 1.7对工作副本格式进行了重大更改。在之前的Subversion版本中,当执行写操作时,Subversion会自动将工作副本更新到新格式。然而,Subversion 1.7将使这成为一个手动步骤。在使用Subversion 1.7与其工作副本之前,用户需要运行一个新命令svn upgrade来更新元数据到新格式。这个命令可能需要一段时间,对于一些用户来说,直接检出一个新的工作副本可能更实际。
注意:Subversion 1.7无法升级那些1.6客户端在运行 svn cleanup(使用1.6客户端)之前已经拒绝操作的工作副本。换句话说,在升级到1.7之前,必须使用1.6客户端在所有需要清理的工作副本上运行svn cleanup。我们对此限制感到遗憾,但我们必须引入它以便及时发货并不过度复杂化内部结构。
svnadmin pack
。svnadmin pack
之前在每个仓库上运行svnadmin upgrade
。fsfs-reshard.py
脚本感兴趣,以在打包之前估计和调整分片大小,并解压缩已打包的仓库。当我们从SVN 1.6升级到SVN 1.8时,SVN 1.8客户端在检出和提交方面表现得非常好,但是在尝试进行合并时,它会报告以下错误:
svn: E200020: Invalid revision number '0' found in range list
这是因为 SVN 1.6 在 svn:mergeinfo
属性中放置了修订版本 0,而 SVN 1.8 客户端不再允许此操作。
我们不得不重写整个 SVN 存储库历史,并将任何提及修订版本 0
的内容替换为修订版本 1
在我们的 svn:mergeinfo
属性中。我们编写了一个 svndumpapi 来进行此操作 replacement。