Visual Studio + svn：在网络驱动器或本地工作副本？

Question

我们（小团队）目前在网络驱动器上安装我们的Visual Studio项目（没有版本控制）。我希望我们开始使用版本控制，所以我想我会安装Subversion并将所有项目放入svn存储库。

现在问题是：我们应该把工作副本放在哪里？

• 选项A：在本地硬盘上。优势：编译速度很快。
• 选项B：服务器上的网络共享（每个用户一个目录）。优点：所有工作副本都将包含在每日备份中。

理想情况下，我希望有两个优点，但我想这是不可能的（至少没有重新制定我们的备份策略来包含工作站）。或者有可能吗？或者是否有任何其他观点支持或反对选项A和B？

Answer 1

我坚持使用选项A的原因很简单：开发人员更有可能提交他们的更改，而不是留下工作副本，因为他们知道他们正在备份。设置svn服务器并将其置于备份计划中。

Answer 2

使用选项A.如果通过备份subversion服务器来备份subversion存储库，则无需备份工作副本 ^* 。当更改提交到SVN时，它们会被转移到SVN服务器，因此只需备份服务器即可备份工作副本，禁止任何未提交的更改。

此外，Subversion在与SVN服务器通信时非常适合网络传输，但对于工作副本的磁盘使用/访问非常重要。通过将工作副本放在远程文件共享上，您将获得两种情况中最糟糕的情况。

---

^* 任何未签入SVN的更改都不会被备份，但我建议您鼓励人们定期提交。如果由于部分完整的功能而导致这不容易，请查看branching in SVN。您可以为每个开发人员提供自己的分支进行开发，并且只有在更改完成后才将其更改合并回主干。

Answer 3

出于上述性能原因，绝对是本地的，尽管我认为这可能适用于任何语言。

你引用它们的原因是备份。如果这是唯一的原因，我可以告诉你我与各种源控制提供商合作的经验让我发现通常如果你失去了你的本地变化（顺便说一下非常罕见） ，他们不是那么多，你不能重新创造它们。您的源存储库应位于备份驱动器上，因此绝大多数代码都是安全的。只有当前任务的代码值才会在驱动器发生故障时丢失。如果您对此感到担心，请推广足够小的工作单元（如果可能的话），以免任何人失去超过一天的工作。或者我想如果你有更大的工作单元并且每天提交到分支机构并在更方便的时候将它们合并回主干线，你可以分支你的代码。

Answer 4

你正在使用C ++吗？编译速度足够慢，不要低估编译时间对您的工作效率的影响。您的本地工作站有许多免费备份解决方案。

在工作中，我们使用TFS设置仅包含我们已更改的文件的本地副本。每次我打开一个没有缓存的文件时，它会滞后几秒钟才能获取它。难以忍受。

Answer 5

我一直发现从网络驱动器运行代码存在安全问题，所以我要说去当地并经常办理登机手续。

此外，如果您开始使用visualsvn或tortoise等工具，他们更有可能在本地驱动器而不是网络上执行。