3

我们在办公室的开发服务器上保存了三个网站的 SVN 工作副本。服务器 WAS Linux，工作副本在 Windows 机器上工作，并使用 TortoiseSVN 更新/提交等。我会先说我知道网络共享上的工作副本不受严格支持，但这样做是为了在将它们放到实时服务器上之前，我们可以在本地开发 URL 上离线测试我们对站点的代码更改。

这工作非常出色。完全没有问题 - 直到我们的 Linux 服务器出现问题并不得不更换。我们已将其替换为 Mac，以扼杀在内部使用 Mac 进行浏览器测试的第二只鸟。

自从把所有东西都移到 Mac 上之后，SVN 就一直是个大问题。提交/更新通常会因“数据库已锁定”错误而失败，而且我大部分时间都无法清理，因为它通常会因以下错误而失败：

清理未能处理以下路径： PATH TO WC ON NETWORK 数据库已锁定，正在执行语句 'COMMIT TRANSACTION;'

正在执行的语句不同，有时与 RELEASE 有关。

我们所做的代码更改必须在我们的开发服务器上进行测试，然后才能在线提交到实时站点。就目前而言，我现在在自己的硬盘上签出了一份工作副本。我必须提交我的更改，在开发服务器上更新（并祈祷它可以工作 - 无论哪种方式都需要 AGES）并测试它们，然后在它们工作时更新实时服务器。

我也无法在网络共享上签出新的工作副本 - 再次，它通常无法抱怨磁盘 I/O 错误或数据库被锁定。我们已经禁用了 Mac 的所有省电功能，以防睡眠或硬盘减速导致 - 运气不好。

如果可能，我希望将工作副本保留在网络共享上。正如我已经说过的，我意识到这不是执行 SVN 的最合适的方式，但它一直在为我们工作。我可以做些什么来尝试解决这个问题？我怀疑它与 Windows -> Mac 网络相关，实际上还有另一个问题是关于从我的机器到 Mac 网络共享的慢速网络访问。

4

3 回答 3

2

从 SVN 1.7 开始，SQLite 被用作工作副本的数据库。如SQLite 版本 3 中的文件锁定和并发中所述：

SQLite 使用 POSIX 咨询锁来实现 Unix 上的锁定。在 Windows 上，它使用 LockFile()、LockFileEx() 和 UnlockFile() 系统调用。SQLite 假定这些系统调用都像宣传的那样工作。如果不是这种情况，则可能导致数据库损坏。应该注意的是，已知 POSIX 咨询锁定在许多 NFS 实现（包括最新版本的 Mac OS X）上存在错误甚至未实现，并且有报告称 Windows 下的网络文件系统存在锁定问题。您最好的防御措施是不要将 SQLite 用于网络文件系统上的文件。

看来这是你的问题。您应该使用本地工作副本以避免出现问题。在开发过程中，您可能会获得额外的性能提升，因为文件 I/O 可能会减少。

关于您的部署服务器，您可能会考虑使用诸如TeamCity或Hudson之类的集成服务器，一旦正确配置就可以将您的更改自动部署到您的开发服务器上（例如，在每次提交时）。

于 2012-11-13T12:23:27.913 回答
1

类似问题已在此处得到解答- SVN 中的工作副本 XXX 被锁定且清理失败

它可能不是理想的方法，但它可以帮助您解决锁问题。

考虑每次都检查到新目录，而不是用新目录替换旧目录

于 2012-11-13T12:13:47.703 回答
1

当您更换服务器软件时，您访问这些“网络共享”的方式很可能已经改变。因此，您现在很可能面临与以下事实相关的不同（更多）问题：通过网络共享访问 svn checkouts 无法可靠地工作。

但是，为什么要进行共享结账呢？对所有开发系统进行单独检查并单独提交更改更有意义......

于 2012-11-13T12:09:51.510 回答