如果愿意，是否应该允许开发人员使用VSS？

我向公司介绍了Mercurial。我喜欢它，但这是我的第一个版本控制经验。我将其与NetBeans PHP一起用于Web开发。

另一个从事公司内部应用程序开发的开发人员喜欢使用Visual Source Safe，并且不想切换。他在Visual Studio环境中工作。

除此以外，所有其他开发商都购买了Mercurial。不过，在大多数情况下，我们所有人都非常独立地工作。

我正在努力朝着正确的方向发展这个部门，我已经为每个人在Kiln上建立了一个帐户，我希望也能使每个使用Fogbugz的人都走上一条路（因为目前没有维护任何错误数据库。）从未使用过VSS，但我听说过非常糟糕的事情。

如果他愿意，只允许他继续使用VSS会更好，还是让他加入Mercurial符合最大利益？

如果那是他更喜欢的，允许他继续使用vss会更好吗？

不可以。并行运行两个不同的源管理系统没有意义。这违背了所有开发人员都连接到同一个存储库并充分利用它的想法。

一个单独使用不同系统的开发人员可以有效地将自己与团队隔离。即使项目不交叉，这仍然是一件坏事。

这两个系统的维护工作加倍是这里的另一个论点。

我认为您应该使用权限或将此问题上报给管理层，以将内容从VSS快速迁移到Mercurial，然后关闭VSS。

PS说到VSS，当您最不希望它丢失检入或损坏代码时，这是众所周知的。它确实有效，但它经常使人紧张。如果您有更好的选择，请避免使用VSS。

我绝不会考虑允许流氓开发人员使用与团队其他成员不同的源代码控制系统。

源代码控制不仅可以使我找到以前做过的版本，还可以让其他人找到它们（以及当前版本）。这是不可谈判的。当他离开或被公交车撞倒而其他人无权访问他的代码（网络管理员在擦拭他的机器而又不知道他在那里拥有自己的源代码控制权，甚至可能被网络管理员覆盖）时，会发生什么？

我确实假设他的源代码控制代码可能仅在他的机器上，因为没有其他人使用VSS。）一个甚至会提出这样的建议的开发人员都不专业，这会让我怀疑他的所有工作。他不希望其余的人看到什么？

VSS也是臭名昭著的越野车。他的代码在那里甚至都不安全。

首先，任何人都不应使用VSS。

告诉您的开发人员获取用于Visual Studio 的Mercurial插件。

每个人都应使用相同的源管理系统。另外，您的最终目标是也使每个人都使用相同的错误跟踪系统。您已经找到了紧密集成的解决方案，做了正确的事情。

如果您在让他们切换时遇到困难，请尝试从职业的角度进行尝试。如果他们在其他任何地方工作，那么未来的雇主可能会希望看到一些使用集成错误/源管理应用程序设置的经验。

要回应别人所说的话，让他使用VSS而不是Mercurial不好。但是，让我扮演魔鬼的代言人，说，只有在他仍然致力于Mercurial的情况下，您才能让它滑行，以便其他人在必要时可以访问他的作品。只要您不阻止其他人访问他们可能需要的工作，那么使用IMO首选工具就没有错。当然，VSS是垃圾，因此无论如何都不应使用它：)

例如，我在一家使用SVN的公司工作，但没有正确设置存储库（没有分支机构/标签/主干，所有内容都被扔到一个存储库中），这会导致一些问题，没人知道如何解决。如果我在本地使用Git，但仍然使用git-svn将我的东西推送到SVN上，那么我的情况就不会出现问题，因此团队的其他成员都可以使用。那有意义吗？

让一名开发人员使用其他源代码管理工具不是很好。使用源代码控制的目的之一是改善团队合作。而且他违反了这个规则，可能会在以后造成很多麻烦，尽管您最近的工作非常独立。问他为什么他更喜欢VSS，并告诉他使用这种方法的弊端。