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

Question

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

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

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

理想情况下，我希望同时拥有两个优点，但我猜这不可能实现（至少不是不重新设计我们的备份策略）。或者有其他支持或反对选项 A 和 B 的观点吗？

- Heinzi

Answer 1

我建议选择选项A，原因很简单：这样开发人员更有可能提交他们的更改，而不是将工作副本留在那里，因为他们知道它们正在备份中。设置svn服务器并将其放入备份计划中。

- Otávio Décio

Answer 2

选择方案A。如果通过备份Subversion服务器来备份您的Subversion存储库，则无需备份工作副本^*。当提交更改到SVN时，它们会传输到SVN服务器，因此仅备份服务器实际上相当于备份工作副本，除非存在未提交的更改。

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

---

^* 任何未提交到SVN的更改都不会被备份，但我建议您鼓励人们定期提交。如果由于部分完成的功能而难以实现，请参考 SVN中的分支。您可以为每个开发者提供他们自己的分支进行开发，并在更改完成后将其合并回主干。

- adrianbanks

---

强调不要备份工作副本，这点非常重要。鼓励团队尽早、经常地提交代码，或者如果符合开发风格的话，可以在私有分支上进行开发。 - the_mandrill

同意 - 经常检查，并在您正在处理的内容不适合时进行分支。话虽如此，备份开发人员的工作站非常简单，为什么不额外做一下呢？ - Bryan Batchelder

在SVN中分支技术上是可行的，但根据我的实际经验，这种方法非常令人沮丧且毫无用处。 - Dustin Getz

在我工作的地方，我们一直这样做。目前我们有几个功能分支正在进行中，还有一些个人分支供个人使用。 - adrianbanks

Answer 3

出于以上性能原因，建议将代码保存在本地，但我认为这对于 任何一种 语言都适用。

你提到将代码保存在共享文件夹中的原因是数据备份。如果这是唯一的理由，那么我的工作经验告诉我，与源代码控制提供者合作的经验表明，通常情况下如果你丢失了本地更改（非常非常罕见），那么这些更改并不多，可以重新创建。您的源代码存储库应该在备份驱动器上，因此您的大部分代码都是安全的。只有当前任务的代码在驱动器故障时才会丢失。如果您担心如此，可以按较小的工作单元进行推进（如果可能），以使每个人丢失的工作量不超过一天。或者，如果您有更大的工作单元，可以进行分支，并在每天提交到分支，并在更方便的时间将其合并回主干。

- Jim L

---

此外，您可以鼓励开发人员运行类似 SyncToy 的工具，让它在夜间运行，这样如果开发人员积累了超过一天的待处理更改，这些更改也会得到备份。这保证了即使开发人员数天不提交代码，也不会丢失超过一天的工作成果。 - itowlson

Answer 4

你是否正在使用C ++？编译足够缓慢，请不要低估编译时间对生产力的影响。有很多免费的本地工作站备份解决方案。

在工作中，我们使用TFS设置只有已更改文件的本地副本。每次我打开未缓存的文件时，它都会延迟几秒钟去获取它。非常痛苦。

- Dustin Getz

Answer 5

我一直觉得从网络驱动器运行代码存在安全问题，因此建议本地运行并经常检查。

另外，如果您开始使用像visualsvn或tortoise这样的工具，它们在本地驱动器上比在网络上更容易实现高性能。

- Jason Punyon