如何将 svn 存储库路径设置为服务器路径？答案

【问题标题】：How to set an svn repository path to a server path?如何将 svn 存储库路径设置为服务器路径？
【发布时间】：2009-05-29 20:43:06
【问题描述】：

SO 上有人说设置源代码控制，需要 5 分钟。它需要很长时间，它很繁琐，而且很痛苦！而且我不明白工作流程

无论如何。我在 server1 上安装了 svn。 Server1 还用于存储我们所有现有的源代码和项目，这些源代码和项目现已添加到 server1 上各自的存储库中。我们有三位开发人员在机器 1、2 和 3 上工作。当我们在 Visual Studio（使用 VisualSVN）中打开服务器 1 上的工作副本项目时，repos 的文件路径当然是 file:///d:/foo提交您会收到一条错误消息，指出 file:///d:/foo 无法找到，因为它在服务器上而不是机器上。

如何让它指向 file://\server/d$/foo？

我试过了

svn switch --relocate file:///d:/foo file://\server/d$/foo

没用

我无法理解的工作流程部分是这个。如果我检查一个类项目的工作副本并编译它。我是否将新的 dll 从我的工作副本移动到生产环境？还是我将 dll 重新检入源代码管理，然后将其从源代码管理移至生产环境？如果多个项目使用该 dll，我是将其从源代码控制中取出到所有项目都查找的某个文件夹中，还是将其复制到所有项目的 bin 文件夹中。头痛

编辑： 感谢您的所有意见，我会坚持下去！

【问题讨论】：

如何为存储库提供服务？它是 Server1 上的本地存储库吗？您在哪里签出工作副本：是您现在尝试通过网络使用的 Server1 上的本地签出（即每个开发人员都在同一个工作副本上工作，这是错误的：每个开发人员都应该有自己的工作副本) 还是检查到每个开发人员的机器？工作流程和其他 SVN 内容在这里得到了很好的解释：svnbook.red-bean.com/en/1.5/index.html

标签： svn

【解决方案1】：

是的，源代码管理只需要几分钟的时间来设置，但是，了解它的工作原理是关键。

为了回答这个问题，最好解释源代码控制的工作原理以及您应该期望从中得到什么。

http://svnbook.red-bean.com/ 这本书（您可以直接在线阅读）对它的工作原理进行了精彩的解释。前几章是您真正需要浏览的所有内容，以便掌握基础知识。

一旦你掌握了书中的基本大纲，你的实现哪里出了问题就会变得很明显。

【讨论】：

我强烈推荐阅读 svnbook，它写得很好，易于阅读。

【解决方案2】：

我怀疑您使用 UNC 名称以便在仍然使用 file:// 方案的同时拥有基于网络的存储库是这里的问题。回购主机上应该有一个 SVN 服务器。这将不会使用 file:// 方案联系。

关于检查编译输出，简而言之，不要。颠覆中的内容应该可以由每个客户从头开始构建。编译后的二进制文件在 subversion 存储库中没有位置，除非（可能）它们来自第 3 方并且对构建至关重要。

“如果多个项目使用 dll 怎么办，我是将它从源代码控制中取出到所有项目都查找的某个文件夹中，还是将它复制到所有项目的 bin 文件夹中”... 否回答。对不起。

【讨论】：

【解决方案3】：

SVN Book 建议您不要对多个用户使用 file:// 协议

Choosing a Server Configuration:

不要被让所有用户直接通过 file:// URL 访问存储库的简单想法所迷惑。即使每个人都可以通过网络共享随时使用存储库，这也是一个坏主意。它消除了用户和存储库之间的任何保护层：用户可能意外（或故意）损坏存储库数据库，使存储库脱机以进行检查或升级变得困难，并且可能导致文件权限问题混乱（请参阅名为“支持多种存储库访问方法”的部分）。请注意，这也是我们警告不要通过 svn+ssh:// URL 访问存储库的原因之一——从安全角度来看，它实际上与本地用户通过 file:// 访问相同，并且可能会带来所有相同的问题如果管理员不小心

【讨论】：

【解决方案4】：

尼克：

坚持住。不要放弃源代码控制！相信我，您现在的学习曲线将在未来得到回报。

Re：您的工作流程问题，您遇到了如何构建软件的问题。这里有很多方法可以使用，但基础是这样的。当您编译您的应用程序时，请确保您的工件（.exe、.dll 等）标记为 svn:ignore（在 Tortoise 中，您只需说“添加到忽略列表”）。这将使 SVN 无法检查您的构建。您不希望从开发人员副本中签入构建工件，因为它占用了大量空间，并且会产生大量冲突。

您有几个选择，但我会根据您告诉我的内容为您的工作流程提出建议：

在源代码管理之外构建您的 DLL。在 SVN 中，为您的“已发布”代码设置一个目录——对我来说，它是我的项目下名为“releases”的目录。然后，当您的 DLL 被测试和验证时，给它一个版本号并将其签入您的“发布”部分。告诉您的开发人员，他们可以使用您的共享 DLL 的新版本，并让他们知道这些更改是什么。然后他们可以随意拉下您的 DLL 并将其集成到他们的代码中。

一旦您对 SVN 感到满意（它会发生！），您就可以继续使用 Hudson 或 CruiseControl.NET 之类的东西，它们位于您的网络上并监控 SVN 的变化。当他们检测到更改时，他们会根据您指定的方式自动构建您的软件。这使得所有这些围绕业务的复制完全自动化。即使没有 CCNET，您也可以使用 nAnt 或 MSBuild（我个人使用 MSBuild）制作“构建文件”，它会根据您选择的方法为您完成所有这些复制工作，因此您不必做所有每次您想要构建时都会使用此手册。

【讨论】：