我们应该如何应对我们的应用程序的重大变化？

Question

我们拥有这个庞大的应用程序，在源代码管理中有18个项目（VSS）。

每当我们处理小的更改时，一切都很好，因为每个开发人员都有一些文件签出给自己，希望在签入之前没有人需要它们（大约需要4到8个小时）

但是，当我们想要进行重大更改时，开发人员会将这么多文件保留几天，并让其他人难以完成分配的任务。

以下是一个场景： 上周我们想要实现一个功能，它将使用分页机制获取应用程序中的每个列表。因此，我们应该更改UI，业务和数据访问层。 有一个开发人员分配给这个任务，她检查了很多文件，她阻止了其他任务。

我们应该如何计划开发这些功能？

Answer 1

切换到更好的版本控制系统。 VSS受设计问题及其硬锁原则的影响。 Subversion免费提供，可用于大规模应用程序开发。分支和标记是廉价的操作，没有硬锁。

您的公司将使用Subversion更好地生活。试试吧！

Server易于在任何系统上设置（Windows / Linux）

TortoiseSVN Windows内置于Windows资源管理器中的客户端

SVN Manual至少阅读前几章

还有许多其他选择，但VSS是大规模开发的痛苦。由于有更好的免费解决方案，为什么要坚持供应商？

Answer 2

VSS sucks，迁移到真正的SCM，microsoft可能会帮助您无缝升级到没有此问题的TFS。或者迁移到任何一个FOSS SCM，比如颠覆，但过渡可能会更难（但可能更便宜）。

Answer 3

如果现在无法升级到真正的VCS，请让执行主要功能的人下载所有内容的本地副本，然后在版本控制之外进行更改。立即合并（周末或某些事情，以防它变得复杂）。

  

这对于在进行“重大更改”时需要版本控制的开发人员来说无济于事

嗯，你做的就是你要用的工具。他总是可以安装一个现代的VCS，比如git，它可以在本地运行。只需将整个基线检查为git（减去历史记录）并转到。

Answer 4

您是否考虑过分享和分支？此外，您可以允许具有经验的用户进行多次结帐。在您进行大型应用程序更改的情况下，我建议标记然后创建分支。如果某些事情发生了“重大变化”，那么您就不会使用生产版本。您可以在已发布的代码中快速修复，然后在准备就绪后将它们合并为“重大更改”。请查看帮助主题“共享和分支”。

Answer 5

使用在合并模式（乐观）下工作的版本控制系统，而不是锁定模式。

合并模式是乐观的，它假设通常不会在同一个地方进行更改。如果它发生在同一个地方，那么通常很容易解决。

可以在合并模式下工作的版本控制系统的示例是CVS。它现在已经过时，但其他的存在。

Answer 6

SVN是您解决问题的答案。我已经习惯了它并轻而易举地学习/使用它。但是有一些新的孩子在街区。试试GIT。我一直听到很多关于它没有机会尝试的事情

Answer 7

VSS只是一个古老的故事，我们现在使用Subversion（服务器）和TortoiseSVN（客户端）。 （这只是基于我们的偏好） 顺便说一下，只迁移到其他版本控制/源代码控制 - 不会解决您的团队问题。问题在于沟通。如果她不能与其他人沟通并坚持她的习惯（在没有检查的情况下处理大量文件），她会让你的团队失望，你必须让她知道如何使用版本控制与团队合作。如果没有，她会在使用Subversion时让你陷入“合并”问题。 ^^

Answer 8

您已经获得了有关更改为可用VCS的建议。

在此之上，您和开发人员应该训练将重大变化分解为较小的变化。我考虑每天大约10次提交和全职开发人员正常率。它使锁定更加痛苦。

原则应该是：尽可能做出最小的改变，使你达到理想状态并工作（如软件编译并通过所有测试）。

在你草拟的情况下。将参数添加到一个图层，并更改对该图层的所有调用（可能具有虚拟值）将是一个更改。实际上使用这个值，将是另一个变化。

这样可以在更短的时间内锁定更少的文件。

Answer 9

长期来看，您需要迁移到另一个VCS。正如其他人所提到的，如果你想坚持使用MS，可以考虑开源或TFS。 （我们使用TFS，但我不会赞美它 - 没关系。）正如AMissico所提到的，分支将有助于任何支持它的VCS。学习有效地使用分支并非易事，需要学习和/或培训。

Continuous Integration也会有所帮助。 TeamCity是我们使用的，设置起来相对简单。请参阅FeatureBranch。