安全地在OS之间共享Subversion工作副本？

Question

我过去曾听说在操作系统之间共享Subversion工作副本是不安全的。

E.g：

1. 将工作副本从Windows计算机复制到Linux计算机，并在其上使用Linux版本的SVN。
2. 在Windows计算机上，使用SVN的Windows二进制文件和CygWin二进制文件访问/操作SVN工作副本。 （我可能想要这样做以使用this solution）。

但我没有明确地听到它是否会导致.svn数据的破坏。如果 svn：eol-style 设置为原生，则EOL问题确实存在问题。

这个问题的现状是什么？它是否在最新版本的SVN中发生了变化？如果采取了某些预防措施（例如，在两个平台上都没有使用 svn：eol-style = native 检查/更新文件），它是否安全？

Answer 1

我在unix，linux，solaris和windows之间的共享网络目录中使用了svn;有趣的是，我遇到的唯一问题是不同的svn客户端版本是“无法比拟的”。 linux和unix机器配备了比solaris svn更旧的svn版本;这比Windows机器客户端更老了。结果是运行'svn up'将元数据文件更新为正在运行的客户端;并且客户端不会访问具有更新元数据版本的文件。最终结果是svn客户端应保持相同的版本号。

所以，是的，我已经能够以最小的生命损失在机器之间移动工作目录。也就是说，我从未使用超出默认值的任何svn选项。

Answer 2

我的svn存储库在Linux上。我在Linux上有一个工作副本，在WindowXP上有另一个。

在WindowXP上，我使用cygwin访问我的工作副本。有时，我也使用Tortoise来获得视觉差异，文件的完整历史......

我从未尝试从使用svndump创建的Linux存储库恢复（或创建备份）到Window计算机。

[编辑]

我忘了提及更新与两个工作副本完美配合。

Answer 3

根据我的经验，它有效。

但Windows和Linux之间有时会出现区分大小写的问题。文件夹“构建”和“构建”冲突和“.htaccess”之类的东西。但没有什么难以解决的。

Answer 4

正如CoderTao所提到的，在工作副本上使用不同版本的svn（客户端）会导致静态WC格式升级，所以一定要坚持使用单个版本系列来避免这种情况。

除了你的主要问题，我看到你正在通过一个慢速链接使用SVN repo。您可能希望查看专为此类事物设计的分布式源代码控制系统。

例如，Bazaar（bazaar-vcs.org）有一个bzr-svn插件，允许您创建远程SVN仓库的本地分支。然后你有一个快速的本地分支，你可以检查到多个位置，在本地工作，差异，浏览历史记录等。您可以在本地提交并保持您的单独的本地（日本）分支同步，而无需缓慢提交到澳大利亚。一旦一切顺利，您就可以将更改推回到SVN上游。如果您有兴趣，Bazaar维基上有很多工作流示例文档。 :)

Answer 5

除了其他答案（因为他们似乎认为这是可行的），我可以断然报告共享一个工作副本（在我们的例子中通过Samba共享）我们在其中使用了“svn：eol-style native” 为我们造成了问题，我们试图避免它。

如果我们需要在机器之间复制一个工作文件夹（一种更有限的共享形式，可能是一次性操作），我们期望必须进入并对所有svn：eol风格的文件执行CRLFTOLF转换，实际上我们过去已经通过编写实用程序来遍历树，检查svn属性以及根据需要转换文件（所有这些都在Python中）来完成。

所以为了记录，我明确地说明这个 是个问题。