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

如果现在还不能升级到一个真正的VCS,那就让做主要功能的人下载所有内容的本地副本,然后在版本控制之外进行更改。一次全部合并(在周末或其他什么时候,以防它变得复杂)。

这无助于开发人员在进行“重大更改”时需要版本控制

好吧,你用你的工具做你该做的事。他总是可以安装一个像git这样在本地工作的现代风投。只需将整个基线检查到git(减去历史记录)中,然后继续。

切换到更好的版本控制系统。vss存在设计问题及其硬锁原理。颠覆是免费的,可以用于大规模的应用程序开发。分支和标记是廉价的操作,没有硬锁。

你的公司肯定会在颠覆中活得更好。试试看!

Server 在以前的系统(Windows/Linux)上易于设置

TortoiseSVN 集成在Windows资源管理器中的Windows客户端

SVN Manual 至少读前几章

还有许多其他的替代方案,但vss是大规模开发中的一个难题。既然有更好的免费解决方案可用,为什么要坚持供应商?

VSS sucks ,迁移到一个真正的供应链管理,微软可能会帮助您无缝升级到tfs,这是没有这个问题的。或者迁移到任何一个foss scm,比如subversion,但是转换可能会更困难(但可能会更便宜)。

你考虑过共享和分支吗?此外,您可以允许与有经验的用户进行多个结帐。在您进行大型应用程序更改的情况下,我建议标记然后创建分支。如果发生了“大的变化”,你将不会生产版本。您可以在发布的代码中进行快速修复,然后在准备好后将它们合并为“大更改”。检查帮助主题“共享和分支”。

使用以合并模式(乐观)工作的版本控制系统,而不是锁定模式。

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

一个可以在合并模式下工作的版本控制系统的例子是CVS。现在已经过时了,但还有其他的。

SVN是你问题的答案。我用它来学习/工作是轻而易举的事。但这里有几个新来的孩子。尝试 GIT . 我听了很多关于它的事,虽然还没有机会尝试

vss只是一个老故事,我们现在使用subversion(服务器)和tortoisesvn(客户端)。(这只是基于我们的偏好) 顺便说一句,迁移到其他版本控制/源代码管理(仅限)并不能解决您的团队问题。问题在于沟通。如果她不能与其他人沟通,并保持她的习惯(与很多文件一起工作而不检查它们),她会让你的团队失望,你必须让她知道如何使用版本控制与团队合作。如果没有,她会在使用subversion时将您置于“合并”问题中。^ ^

你已经得到了换成可用风投的建议。

除此之外,您和开发人员应该接受培训,将大的更改分解为小的更改。我会考虑每天约10次提交,而全职开发人员是一个正常的速率。它使锁不那么痛。

原则应该是:尽可能地进行最小的更改,使您达到所需的状态并正常工作(就像在软件中编译并通过所有测试一样)。

以防你勾勒出来。向一个层添加一个参数,并更改对该层的所有调用(可能有一个伪值)将是一个更改。实际上使用这个值,将是另一个变化。

这将导致锁定文件的时间更短。

从长远来看,你会希望转移到另一家风投公司。正如其他人所提到的,如果你想坚持使用m s(我们使用tfs,但我不会赞扬它——没关系),可以考虑使用开源或tfs。正如amissico所提到的,分支将有助于任何支持它的风投。学习有效地使用分支并不是一件小事,需要学习和/或培训。

Continuous Integration 也会有帮助。 TeamCity 是我们使用的,而且设置起来相对简单。见 FeatureBranch 。