我有一些旧的代码（旧的但仍然维护的VB6应用程序），从源代码管理的角度来看，这是管道工的管道（或鞋匠的鞋子）的最终例子。它是由为每个版本创建一个新目录的方法控制的版本。
采取以下方法是否有任何重大缺点？
请注意，我有一个常规更改日志文本文件，我会从我签入/提交的每个版本中获取注释。我没有（或者真的关心这一点）基于每个文件的评论。
我现在还不知道哪些文件在版本之间发生了变化，而且很懒，我想我可以避免在版本之间进行文件比较以找出，所以这就是我采用上述方法的原因。更不用说首先擦除所有文件允许检测文件删除。
我特别没有提到我正在使用哪个版本控制工具，因为我希望（也假设，但可能非常错误）答案是相当独立的。当我使用像“签到”这样的术语时，我会在一般意义上使用它们，而不是特定于工具。
答案 0 :(得分：1)
这是一种合理的方法。某些源控制系统（例如TFS）将默默地忽略检入未更改文件的尝试。这是一件好事。如果你的没有这个功能，我建议在所有文件中进行差异，只检查更改的文件。否则，您会在文件历史记录中添加大量噪音。
答案 1 :(得分：1)
以前版本的更改是否有价值？
如果这或多或少地解决了代码并且它不是维护产品的发布历史的一部分，那么维护历史可能没什么价值。将目录压缩到某处（以防万一）并将最新版本放在源代码管理中。可能没有必要做一大堆工作来创建一个很少或没有价值的历史。
例如，当转移到新的修订控制系统时，许多组织可能只是用现有系统的头部（或者可能是一组分支）启动新系统，并且必须返回遗留系统以获取任何历史记录超出转换日期。