仅针对生产代码的Subversion /源代码控制？

我一年前毕业于计算机科学学院，现在在一家小型Web开发公司（我和另一个开发人员，加上经理，客户服务和测试人员）工作。直到我开始之前，还没有源代码控制系统。我们现在正在缓慢地开始实现SVN，但是另一位（高级）开发人员（此后称为Joe）坚持认为，应该提交给我们的SVN存储库的唯一代码是经过测试并被批准可以投入生产的代码。这意味着，在较大的项目中，可能一次甚至几周都没有提交。

这是正常的做法吗？在我看来，我们失去了很多源代码控制的好处，包括：

• 细粒度跟踪项目进度
• 跟踪出现和解决的问题
• 轻松回滚错误
• 轻松备份代码，因此如果工作站发生故障，我们也不会损失太多
• 更容易识别到底是什么代码运行在生产基地，假设我们盖章的版本到可执行文件所描述的在这里
• 轻松的协作（尽管我们不做任何团队合作；这都是个项目）
• 等等。

编辑：我应该强调，从历史上看，这家公司没有真正的团队合作；只有两个开发人员从事不同的项目。另外，许多项目规模很小，因此可以在几周内完成。该公司已经经营了十多年，并且在没有源代码控制的情况下相处得很好。项目通常在其估计的时间范围内完成。

如果项目在预计的时间内完成，可以安全地假设客户满意吗？:)

看来该公司也开始承接新类型的项目，并且正在经历一些成长中的痛苦或某些“转变中的痛苦”。这里有很多假设...请耐心等待！

如果您确信代码的组织和控制可以在内部帮助您和您的团队，则应考虑使用SVN，恕我直言。如果走这条路线切实可行，并且公司能够生产更高质量的产品，从而赢得更幸福的客户，您将获得奖励积分！

如果似乎与管理人员的挣扎会使工作环境紧张，请当心。事实是业主已经建立了公司。不仅如此，他们还成就了一家成功的公司。他们不太可能赢得大奖，因为他们擅长赌博。

尊重他人，您可能最终会被听到。

希望这将最终导致更高效，更快乐的团队。以我的经验，沮丧的管理很难做到这一点。

乔几乎是完全错误的。现在，您可以说您拥有一个“干净的”分支，该分支代表经过审查的，可投入生产的代码。但是坦白地说，在准备好东西之前不使用源代码控制是自欺欺人的。有点像是在没有杜松子酒的情况下尝试制作马提尼酒。

“高级”实际上是非常不熟练的。任何可以编译的代码（如果有的话可以通过测试）应该提交给源代码管理。源代码控制是用于共享代码和逐步构建软件的中心资产。

好处是分离生产代码（最后一个稳定的版本），但在这种情况下，源代码控制系统包含标签/标签和分支之类的功能。

如果有人在两三天内不做任何事情，我们的团队会非常怀疑。这意味着他有一些问题，也许需要帮助。源代码控制的另一点是，通常定期对其进行备份，而对于开发机而言则不是这样。如果磁盘崩溃，您将失去数周的工作。

撇开Joe是对还是错（顺便说一句，他错了）的问题，在我看来，如果您使用像Git或Mercurial这样的分布式版本控制系统，可能会达成妥协。

这样，您自己和其他开发人员将可以在您的本地存储库上工作，将您的更改尽早地并经常地提交给源代码管理，但是除非将其更改“测试并批准为可用于生产环境”，否则不要将更改推送到“生产”存储库中。您将在几周的时间里拥有所有工作的完整历史记录，而Joe将拥有一个原始的存储库，该存储库仅包含变更的历史记录，这些更改已为生产做好准备。

由于您列出的原因，这没有任何意义。就像使用版本控制一样，没有使用版本控制的好处。

我相信Joe并没有理解源代码控制系统不是源代码产品发布的光荣备份，而是对程序员的有用工具，它为未来的自己和同事们在代码进度和成熟度的较小步骤上加了字。也许Joe不习惯与其他人的团队一起工作？

是否曾经考虑过“为什么要添加此代码行”？找到引入它的提交，并查看其注释。如果仅在生产时提交，则注释的具体性不足以对您有用。

我还建议您使用比SVN更强大的工具。您可以在Joel Spoelsky的http://hginit.com/上找到有关这些可能性的很好的介绍。

他使用水银，这些天有几个竞争者。Git被认为非常强大，并且https://github.com/具有一些非常非常有用的工具，并提供免费的入门帐户，因此您可以实际试用。

Joe似乎不了解SVN，请尝试查找有关Branchs，Tags和Trunk ... Tags与Joe想要的一致。对SVN最佳做法的一些阅读不会有什么坏处

从未使用过SVN，所以我不知道该怎么做。我们正在使用ClearCase，这里的做法是让每个开发人员都有自己的开发分支，然后是一个集成分支，在准备开始测试时将其合并到其中，并为集成和经过测试的代码提供一个或多个发布分支。 。

乔是一个黑客，而不是开发人员。他听起来像一个非常好的黑客，但是他对如何使用修订控制是错误的。那么该怎么办呢？

在我看来，您的组织在SVN上进行了投资，这对您挑战Joe并使SVN服务器中的美元投资无效是您的职业限制。设置一个GIT存储库，并使用git svn界面按照您想要的方式工作（这是所有免费软件，安装需要一个小时到一天的时间，所有操作都在您的工作站上进行）。与Joe社交化您的工作流-他可以保留他的“未污染的SVN回购”信仰系统，并在角落（和自我）上保持昂贵的白象的信誉。

我希望在短时间内，乔将研究您的工作方式，并开始这样做。一两年之内，SVN服务器将成为Git存储库。

您可以尝试用上述论据说服乔。如果这样不能成功的话，请在本地使用SVN进行自己的开发工作，并希望Joe有时会选择使用它。如果您无法用论据说服他们，请做您确信的事情并向他们证明它是有效的。一种分布式方法，但具有现有工具。

我要在这里回声@ Carson63000，说我以前已经见过这种态度，这在很大程度上是由于VCS可怕的分支/合并功能所致。有一个分支可以编译并通过测试，并为每个发行版带有标签，这是一个不错的方法，但是不应遵循这一点，即不要提交其他代码。通常，DVCS（尤其是git）使分支成为简单而又常见的操作，它降低了此工作流程的许多难度。

版本控制系统支持标签的原因是因为您可以标记经过认证的代码，但仍可以进行日常工作。只要有生产质量代码，就将其提交给标签，即可完成。您知道在“时间”中的确切点，您必须回头才能获得客户所拥有的东西。而且，您始终可以检查并比较不同版本的代码。这样，您俩都可以对源代码管理数据库中的内容感到满意。它适用于我工作的公司，该公司有100个开发人员，都在同一个项目上工作。它也一定会为您工作。

仅将东西存储在准备交付生产的版本控制系统中是很常见的。自从过去磁盘存储成本为每兆字节数百美元而存储所有内容的成本过高以来，这就是几十年来的历史。

它不再被认为是做事的最佳方法，但是我可以完全理解为什么人们仍会这样做，因为许多较旧的版本控制系统仍在使用中，这使得即使不做其他事情也很困难，并且仍然保留您的知识。每个版本都是（或者更确切地说，如果确实需要返回每个文件，则不检查每个文件上的标签就无法知道任何版本。我已经看到了多个存储库，这是唯一可以恢复旧版本的方法版本是从存储库中检索一个zip文件，其中包含该版本的源代码和二进制文件。