由于缺乏空间和服务器的改进，我不得不迁移SVN服务器。当操作结束时，所有用户都可以毫无问题地访问他们的项目。
但有些用户注意到他们锁定的文件，他们没有，而其他用户可能会锁定它们。
我进行迁移的过程是这样的。
从旧SVN导出到转储文件：
svnrdump dump http://svnserver/path/to/repository > /path/to/file.dump
将转储文件导入新SVN服务器：
svnadmin load --force-uuid /path/to/repository/ < /path/to/file.dump
我重复了没有--force-uuid参数的导入操作，我得到了相同的结果。
有没有办法让文件锁定进行SVN迁移？
谢谢。
答案 0 :(得分：1)
谢谢大家的回答。我知道使用Subversion的最佳实践是使用编辑合并方法。我一直用它。但在这种情况下，必须使用文件锁定。
其他问题是新的服务器环境有不同的操作系统和不同版本的Subversion，所以我不能使用hotcopy。
我找到的解决方案是将lock目录从旧存储库复制到新存储库。 locks目录位于存储库根目录（ / old_server / repository_name / db / locks ）的db目录中。我将其复制到 / new_server / repository_name / db / locks 。两个存储库都具有相同的名称。在这之后，用户得到他们的旧锁，因为没有发生任何事情。
答案 1 :(得分：0)
svnadmin dump
不会复制锁和钩子（如您所见），但您可以使用：
svnadmin hotcopy REPOS_PATH NEW_REPOS_PATH
来自link的说明：
使用svnadmin hotcopy创建的Hotcopies必须移动到服务器上 相同的设置。你应该有相同版本的subversion 安装在两台服务器，同一操作系统等上。
答案 2 :(得分：0)
正如Ivan Jovovic所述，当您复制存储库时，您不会获得某些不是存储库本身的元数据，例如锁。
然而，在大多数Subversion商店中，很少使用锁。事实上，我无法想到我最后一次看到它们被使用过。
旧版本控制系统有一个锁定概念，您必须在编辑之前锁定文件。这就像是一个图书馆，你检查了一个程序，一次只有一个人可以办理结账。问题是这非常低效。如果两个开发人员想要更改同一个文件，则意味着第二个开发人员必须等待他们的工作。如果第一个开发人员需要数天才能完成，那么第二个开发人员必须等待几天。
大约十几年前，一个新的编辑合并概念发生了。在此模型中，两个开发人员都可以进行更改，第一个将更改提交回版本控制系统赢得。如果第二个开发人员想要检查他们的更改，他们首先必须更新他们的工作副本，获取其他开发人员所做的更改，然后检查他们的代码。
所有现代版本控制系统，Perforce，Subversion，Git，Mercurial等现在都使用此编辑合并模型。这只是一种更好的工作方式。
如果您在更改文件之前仍然坚持要锁定文件，则应重新检查您的开发方式。这就是版本控制系统长期放弃这种做法的原因。