在你开始用“不要这样做”、“不好的做法！”来警告我之前。和“学习使用正确的源代码控制”，请先听我说完。我完全意识到注释掉旧代码并将其永远留在那里的做法是非常糟糕的，我自己也讨厌这种做法。
但这就是我所处的情况。几个月前，我作为软件开发人员加入了一家公司。我在公司实习了几个月，最近才加入公司大约一年。我们公司使用源代码版本控制（CVS）但不正确。
这是我的实习和我目前的永久职位所发生的事情。每次我被分配从事一个项目（遗留，大约 8-10 岁）。一位高级同事没有创建 CVS 帐户并让我签出代码并签入更改，而是从 CVS 导出代码，将其压缩并传递给我。
虽然这位同事每隔几周会批量检查所有更改，但我们通常的做法是在实际源代码本身中进行细粒度的版本控制（每个文件的版本增量独立于其他文件）。每当对文件进行更改时，旧代码将被注释掉，新代码在其下方输入，并且整个部分都标有版本号。有关更改的注释放置在文件顶部的一个名为“修改历史”的部分中。最后，更改的文件被放置在一个共享文件夹中，准备好等待批量签入。
/*
* Copyright notice blah blah
* Some details about file (project name, file name etc)
* Modification History:
* Date Version Modified By Description
* 2012-10-15 1.0 Joey Initial creation
* 2012-10-22 1.1 Chandler Replaced old code with new code
*/
code ....
//v1.1 start
//old code
new code
//v1.1 end
code ....
现在的问题是这样的。在我正在处理的项目中，我需要从另一个项目中复制一些新的源代码文件（新的，因为它们以前在目标项目中不存在）。这些文件有很多历史注释掉的代码和基于注释的版本控制，包括通常很长或很长的修改历史部分。
由于这些文件是这个项目的新文件，我决定清理它们并删除不必要的代码，包括历史代码，并从 1.0 版重新开始。（尽管讨厌基于注释的版本控制，我仍然必须继续实践。别问为什么不从 0.1 版本开始......）我在实习期间做过类似的事情，没有人说什么。我的主管已经看过几次工作，并没有说我不应该做这样的清理工作（如果有的话）。
但一位同级同事看到了，表示不推荐，以后可能会造成停机，增加维护成本。一个例子是在另一个项目中对原始文件进行更改并且这些更改需要传播到该项目。由于代码文件完全不同，它可能会导致其他开发人员进行传播时感到困惑。这对我来说很有意义，并且是一个有效的观点。除了乱七八糟的代码带来的不便之外，我找不到任何理由进行清理。
所以，长话短说：鉴于我们公司的做法，在将新文件从项目复制到项目时，我不应该做这样的清理工作吗？在注释中对具有完整历史记录的原始代码（副本）进行更改会更好吗？或者我能为清理工作提供什么理由？
PS to mods：希望您允许这个问题一段时间，即使您出于任何原因确定它不适合 SO。如果有任何不合适的地方，包括标签，我会提前道歉。