所以，你不会听到我说 svn 和 git 不是非常强大和通用的工具，但是对于非本地开发（中央网络共享）来说，它不能很好地发挥作用（两个人实际上可以在同一个文件上工作) 并产生了相当多的开销，所以具体来说，我想知道是否有任何替代方案可以在中央网络共享上运行良好（主要使用的功能是责备和识别稳定代码和开发代码）。
我知道这是一个相当广泛的问题，我希望这属于 Stackoverflow 的范围，但由于类似的问题没有解决，我决定试一试这个问题。
在反应中似乎存在一个常见的误解：现在我们正在使用颠覆，我们正在提交我们的更改，我们正在使用标签来区分版本并仅将已标记的更改推送到生产环境。此外，似乎有人相信本地副本在某种程度上是协作开发的圣杯。让我告诉你，如果你在同一个项目上最多只能与 4 个开发人员一起工作，那么如果你不使用一些需要编译所有代码和单一语法的古老的低级语言，那么处理相同的文件是理想的错误会破坏整个应用程序。确实，偶尔这确实会导致不必要的错误，但总的来说它工作得非常好，并且有助于加快开发速度。实际的主要问题在于，如果不同的人在同一个 svn checkout 上提交和工作，svn 往往会中断很多。此外，还有一些其他的事情往往会引起麻烦（svn 似乎不喜欢坐在共享上，尽管其中一个答案可能有助于“解决”这个问题），但事实是所有这些事情都是由事实上，SVN 和 GIT 都基于个人开发人员在他们自己的本地副本上工作的想法，这与我们正在做的共享代码库上紧密结合的开发风格不符。
经过讨论后，我们得出结论，我们可以想象一个更简单的不太先进的源代码控制系统，更适合这种开发风格（例如，像体验这样的全自动修订跟踪系统）用户拥有谷歌驱动器文件+另外某种形式的“标记”文件），我们认为其他人也必须考虑到这一点，这就是这个问题的来源。如果您认为我们的开发风格很糟糕，请允许我指出，我们公司目前的效率能够达到我们与之竞争的类似大型 Web 应用程序开发公司的 3-5 倍（以及不增长的选择）是有意识的），是的，这种设置是帮助达到这种效率的原因之一，因为无论流行的版本控制系统多么漂亮：它们添加了很多的开销。正如我在下面的评论之一中所说，对于我们来说，设置本地开发环境意味着必须设置大约 50x4=200 个不同的开发应用程序才能运行。这意味着在每个开发系统上都有 3 个不同的 IIS 实例（由于我们正在使用的“插件”的限制以及这个“插件”的 3 个不同版本的必要性），一个 apache/tomcat 实例和一个 apache/jetty 实例. 另外，为每个开发人员在这 5 个实例中分离出 50 个应用程序的不同子集。（而且我什至不想考虑如何让这 5 个实例相互运行，以及如何处理跨应用程序请求）将所有这些与当前设置进行比较，在当前设置中，我们只需要每个应用程序的三个不同实例（开发、暂存和生产）它' s 根本没有道理。而且我什至没有提到公司中只有大约 2 或 3 人知道如何设置这些实例......顺便说一句，这是一团糟（对于新项目，我们已经从这个混乱中迁移出来，但是对于所有旧的仍然支持但无关紧要的项目）。
我试图使这个问题尽可能笼统，以防止它仅适用于我们，但是某些人在某些答案和评论中给出的那种反应令人难以置信的傲慢。老实说，我们已经考虑过这个问题，我问了一个相当具体的问题。如果问题是要寻找 svn/git 的替代方案，那么来给出答案就太冒昧了：“使用 svn”/“使用 git”或“这个问题让我哭了”。并且没有冒犯@David W. 因为与其他一些人不同，我认识到您真诚地试图提供帮助，但在看到这些评论后，我认真地考虑过退出 stackoverflow。</rant>
无论哪种方式，我仍然希望有人能够向我指出一些完全不同的源代码控制方法，但从表面上看，情况并非如此。也许有一天我会自己写，但现在我没有时间，所以我有点希望其他人已经这样做了。