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文件夹中。头痛
修改 感谢您的所有投入，我将坚持这一点！
答案 0 :(得分：6)
是的，源代码管理只需几分钟即可完成设置，但了解其工作原理是关键。
为了回答这个问题，最好解释源代码管理的工作原理以及你应该从中得到什么。
本书http://svnbook.red-bean.com/（你可以直接在线阅读）有一个很棒的解释，说明它是如何工作的。前几章是您真正需要浏览的基础知识。
一旦你掌握了书中的基本概要，就应该明白你的实施出错了。
答案 1 :(得分：1)
我怀疑您使用UNC名称以便在使用file：//方案时可以拥有基于网络的存储库是这里的问题。 repo主机上应该有一个SVN服务器。不会使用file：// scheme联系这个。
关于检入编译输出，简而言之，不要。 subversion中的内容应该由每个客户端从头开始构建。编译的二进制文件在subversion repo中没有位置，除非（可能）它们来自第三方并且对构建是必不可少的。
“如果多个项目使用dll，我是否将其从源代码管理中取出到所有项目所在的文件夹，或者将其复制到所有项目的bin文件夹中”...回答。遗憾。
答案 2 :(得分：1)
SVN Book建议您不为多个用户使用file：//协议
Choosing a Server Configuration：
不要被所有用户直接通过file：// URL访问存储库的简单想法所诱惑。即使存储库通过网络共享随时可供所有人使用，这也是一个坏主意。它删除了用户和存储库之间的任何保护层：用户可能会意外（或故意）破坏存储库数据库，很难使存储库脱机以进行检查或升级，并且可能导致文件权限问题混乱（请参阅“支持多个存储库访问方法”一节。请注意，这也是我们警告不要通过svn + ssh：// URL访问存储库的原因之一 - 从安全角度来看，它实际上与通过file：//访问的本地用户相同，并且它可能带来所有相同的问题如果管理员不小心
答案 3 :(得分：1)
尼克：
挂在那儿。不要放弃源代码控制！相信我，你现在正在学习的学习曲线将在黑线上得到回报。
Re：您的工作流程问题，您遇到了如何构建软件的问题。这里有很多方法可以使用，但基础是这个。编译应用程序时，请确保您的工件（.exe，.dll等）标有svn：ignore（在Tortoise中，您只需说“添加到忽略列表”）。这将使SVN无法检查您的构建。您不希望从开发人员副本签入构建工件，因为它占用了大量空间，并且会产生很多冲突。
您有几个选择，但我会根据您告诉我的内容为您的工作流程提出建议：
在源代码管理之外构建DLL。在SVN中，为“已发布”代码设置一个目录 - 对我而言，它是我项目下名为“releases”的目录。然后，当您的DLL经过测试和验证时，请为其提供版本号并将其签入“发布”部分。告诉您的开发人员他们可以使用您的共享DLL的新版本，并让他们知道更改的内容。然后，他们可以随意下载您的DLL并将其集成到他们的代码中。
一旦你对SVN感到满意（它将会发生！）你可以继续使用Hudson或CruiseControl.NET等东西，这些东西位于你的网络上并监视SVN的变化。当他们检测到更改时，他们会根据您指定的方式自动构建软件。这使得所有这些复制都完全自动化。即使没有CCNET，您也可以使用nAnt或MSBuild（我个人使用MSBuild）创建一个“构建文件”，它将根据您选择的方法为您完成所有这些复制工作，因此您不必完成所有操作每次你想要构建时都会使用这个手册。