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

【问题标题】：Visual Studio + svn: Working copies on network drive or local?Visual Studio + svn：网络驱动器或本地的工作副本？
【发布时间】：2009-10-29 23:21:02
【问题描述】：

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

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

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

理想情况下，我希望同时拥有这两个优势，但我想这是不可能的（至少在不修改我们的备份策略以包括工作站的情况下是不可能的）。或者有可能吗？或者是否还有其他支持或反对选项 A 和 B 的观点？

【问题讨论】：

标签： visual-studio svn

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

此外，Subversion 在与 SVN 服务器通信时对网络传输进行了非常优化，但对工作副本的磁盘使用/访问非常繁重。通过将工作副本放在远程文件共享上，您会遇到两种情况中最糟糕的情况。

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

【讨论】：

+1 强调不备份工作副本。鼓励您的团队尽早并经常提交，或者在适合您的开发风格的情况下在私有分支上工作。
同意 - 经常检查，如果您的工作不合适，请分支。话虽如此，备份开发人员工作站是微不足道的，那么为什么不另外做呢？
在 SVN 中进行分支在技术上是可行的，但根据我的实际经验，非常令人沮丧并且完全没用。
在我工作的地方，我们一直都在做。我们目前有几个功能分支，以及一些个人分支。

【解决方案3】：

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

您引用的将它们保留在共享上的原因是备份。如果这是唯一的原因，我可以告诉您，我与各种源代码控制提供商合作的经验使我发现通常如果您丢失了本地更改（顺便说一句，非常罕见），它们数量不多，以至于您无法重新创建它们。您的源存储库应位于备份驱动器上，因此绝大多数代码都是安全的。如果驱动器发生故障，只有当前任务的代码会丢失。如果您对此感到担忧，请推广足够小的工作单元（如果可能），这样没有人会损失超过一天的工作量。或者我想如果你有更大的工作单元并且每天提交分支并在更方便的时间将它们合并回主干，你可以分支你的代码。

【讨论】：

此外，您可以鼓励开发人员让 SyncToy 之类的东西在一夜之间运行，这样如果开发人员确实累积了超过一天的未决更改，这些未决更改将得到备份。这保证（咳咳）即使几天不提交，任何开发人员都不会损失超过一天的工作。

【解决方案4】：

我一直发现从网络驱动器运行代码存在安全问题，所以我会说去本地并经常检查。

此外，如果您开始使用诸如 visualsvn 或 tortoise 之类的工具，它们更有可能在本地驱动器而不是网络上运行。

【讨论】：

【解决方案5】：

您使用的是 C++ 吗？编译速度很慢，不要低估编译时间对您的生产力的影响。您的本地工作站有很多免费的备份解决方案。

在工作中，我们将 TFS 设置为仅具有我们已更改文件的本地副本。每次我打开一个未缓存的文件时，它都会延迟几秒钟才能获取它。难受。

【讨论】：