作为正常开发过程的一部分，从VCS中永久删除版本是否有意义？

Question

我们在工作场所使用ClearCase。当代码合并到主（主干）分支时，我们标准流程的一部分是完全根除开发和集成分支上的所有版本。因为这会消除与这些版本一起发布的所有签入注释，我们的源文件必须有一个冗长的序言注释，用于标识每个更改。

有几次我指出，这否定了使用版本控制系统的一个基本原因，并指出通过删除版本，我们无法看到谁最初在做什么，当问题被引入时等。检查新版本的人已经学会了不打扰输入签到评论，因为它无论如何都会被删除。

我所听到的删除旧版本的理由通常只是归结为“感觉良好”的原因。我更有经验的同事觉得删除这些旧分支会使文件的版本树“更清晰”。他们声称，一旦将这些旧版本合并到我们的主干上，就没有理由保留它们。他们还担心其他开发人员会意外地将这些过时的分支保留在view config specs中。最后，他们认为删除这些分支可以节省CM服务器上的磁盘空间。

我是否对此有不好的感觉，或者是否有其他开发商店以这种方式成功运营？如果你还认为这是一个坏主意，你会提供哪些其他支持保留旧版本的论据？如果您已成功使用此类流程，您会观察到哪些好处？

---

编辑澄清：以前版本的主干始终保留。它是最初创建或修改的东西被移除的分支。

Answer 1

如果有一件事你没有用ClearCase删除版本。
决不。 （几乎从来没有）。

ClearCase主要基于delta，其基线可以在增量模式下设置，并且需要以前的版本才能使其内容正确，更一般地说，文件的历史就是它的本质。 （和合并历史：rmver将删除所有xhlinks，即所有超链接，如合并信息）

如果您真的要清理历史记录： cleartool lock -obsolete 是正确答案。
只是从你不想再看到的行李箱中淘汰旧的树枝。通常绰绰有余。

唯一可以证明删除版本的案例是：

• 带有“错误内容”的新版本你根本不打算版本：如果它是最后一个版本，没有标签或超链接，你可以删除它而不是更改它......
• 大型二进制文件经常发展（然后rmver旧版本实际上可以保存位置）。所有其他类型的文件都不会通过删除旧版本来保存重要位置。

Answer 2

如果您不打算保留版本，为什么要使用版本控制对我没有意义。

在我看来，版本控制的主要好处是能够追溯到时间。我发现自己经常检查以前版本的文件，以找出改变的原因或方式。

随着需求的发展变得非常方便，您发现自己确实需要三个月前编写的代码。

Answer 3

您已经注意到一个大问题：删除提交注释后，没有自动记录代码的方式。也没有办法检查软件如何成为现实的历史：这是一个很大的问题，大的序言评论可能是准确的，也可能是不准确的。

当我遇到看起来很奇怪的代码时，我想知道它是怎么回事。由于我们使用Subversion，我可以使用“svn blame”来查找该行出现的修订版本，并从那里进行检查。这通常会导致理解代码的目的，并通过更改它给我一个线索。找到添加或删除功能的时间通常也很有用。

虽然这可以节省一些空间，但是一个好的VCS会存储增量，因此不会占用额外的空间（注意：我不知道ClearCase是否以这种方式表现良好）。与此同时，您正在使用的文件会被序言注释所夸大，并且可能会被注释掉或有条件编译的代码膨胀，以防以后它变得有用。

作为过去管理VCS系统的人，只有两个理由可以删除系统中的内容。一个是如果某些东西得到了应该不会，并且导致问题（例如，它可能非常大 - 有些人在有人不仅提交了源文件而是提交了所有二进制文件时遇到了问题），另一个是if它是不合适的（例如机密信息）。

Answer 4

删除版本对我来说是不可理解的。听起来你的同事正在尝试使用ClearCase，而不是提供适当的文档，支持和培训。

不幸的是，我也遇到过非常类似的情况。在开始未来的项目时，您应该尝试为您认为应该如何进行版本控制做出清晰明确的论据。也许如果项目开始的过程正确建立，他们都将看到优势并将其应用于未来的项目。

Answer 5

删除修订信息没有任何好处。即使没有签到注释的修订信息也比没有修订信息好1000倍。

保留修订信息（超出文件恢复）的最引人注目的情况是，当您发现错误并追溯到导入错误的签入时，通常最好同一个用户环顾四周。同一时间。该错误可能比它最初出现的更广泛。没有修订信息就无法做到。

换工作。你会活得更久。与不了解版本控制的好处的程序员合作不利于您的持续健康。

Answer 6

不，我认为这些好处不会超过成本。成本是显而易见的（现有答案很好地涵盖了），所以我将解决所谓的好处。

1. 如果您想要一个“更干净”的源代码树，还有许多其他功能不涉及破坏信息。大多数源代码控制系统都可以将项目置于隐藏在标准UI之外的已删除状态（除非您打开特殊选项）;基于每个项目强制执行读取权限;将项目移动到树的预定义区域（例如，名为“Old Stuff”的地方）;或以上所有。

2. 据我所知，每个功能足以支持自定义视图规范的SCC系统也允许管理员审核并覆盖这些设置。

3. 源代码并不是那么大。考虑压缩+增量存储后，特别是。仅在涉及大型二进制文件的一些小众应用中，我可以考虑永久删除。 （例如，游戏开发工作室通过大量的高分辨率艺术作品和视频。）即便如此，我的保留政策也不会像你描述的那样傲慢。我会以预定义的间隔保留快照。说：所有修订为2周，然后每天修改前2周，每周修订前几个月，然后每月修复一次。

总的来说，开发者的时间确实非常昂贵。只需几分钟的CC管理+ SAN中的一些额外硬盘甚至无法比较。

Answer 7

能够责备某人进行特定更改通常非常有用。一旦所有的变化都在主干中，所有关于谁写了什么以及为什么他这样做的信息都会丢失。能够向某人展示“在这里 - 你这样做，在那里”通常非常有用，即使没有提交评论。

Answer 8

没有版本控制历史记录，一个非常有用的“调试”工具，搜索历史记录中的bug（通过二分）来查找引入bug的第一个修订版是不可能的。当你发现一个引入bug的提交时（某些VCS提供了“scm bisect”命令来帮助解决这个问题，如果你进行了脚本化测试，甚至可以完成自动化），并且你遵循了小型单一问题的良好版本控制实践，描述良好的提交，然后很容易找到错误的位置。