我们在工作场所使用ClearCase。将代码合并到主(主干)分支时，我们标准流程的一部分是完全消除开发和集成分支上的所有版本。因为这会抹去这些版本附带的所有 checkin 注释，所以我们的源文件必须有一个冗长的序言注释，以标识每个更改。
我曾几次指出，这否定了使用版本控制系统的根本原因之一，并指出通过删除版本，无法看到谁最初从事某项工作，何时引入问题等。新版本已经学会了不必费心输入 checkin 注释，因为无论如何它都会被删除。
我听说删除旧版本的理由通常只是归结为“感觉良好”的原因。我经验丰富的同事感觉到，删除这些旧分支会使文件的版本树更“干净”。他们声称，一旦将这些旧版本合并到我们的后备箱中，就没有理由保留这些旧版本。他们还担心其他开发人员会意外地将这些过时的分支保留在view config specs中。最后，他们认为删除这些分支可以节省CM服务器上的磁盘空间。
我对此是否有不好的感觉是正确的，还是那里有其他以这种方式成功运作的开发商店？如果您还认为这是一个坏主意，您还会提出其他哪些主张保留旧版本的论点？如果您在这种过程中操作成功，那么您观察到了哪些好处？
编辑以澄清:始终保留以前版本的主干。原来创建或修改的是那些分支，这些分支被删除了。
最佳答案
您已经注意到一个大问题:由于删除了提交注释，因此并没有自动记录代码的状态。也没有办法检查软件如何发展的历史:这是一个很大的难题，带有大量的序言注释可能是正确的，也可能是不正确的。
通常，当我遇到看起来很奇怪的代码时，我想知道它是如何实现的。由于我们使用Subversion，因此我可以使用“svn blame”来查找该行出现的修订版本，然后从那里进行检查。这通常会导致理解代码的目的，并提供一个线索，告诉我通过更改代码可能会破坏什么。查找何时添加或删除功能通常也很有用。
虽然这样可以节省一些空间，但是好的VCS可以存储增量，因此不会占用所有额外的空间(注意:我不知道ClearCase是否以这种方式很好)。同时，您正在使用的文件会因序言注释而膨胀，并且可能因注释或有条件编译的代码而膨胀，以防以后使用。
作为曾经管理VCS系统的人，只有两个理由从系统中删除某些内容。一个是如果某个东西不应该提交而导致问题(例如，它可能非常大-有些人在不仅提交源文件而且还提交所有二进制文件时遇到了问题)，另一种是这是不适当的(例如 secret 信息)。
关于version-control - 在正常的开发过程中，从VCS中永久删除版本是否有意义？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1446332/