开始告诫我“不要做”，“ BAD PRACTICE ！”并且“学会使用正确的源代码控制”，请先听我说。我完全清楚注释掉旧代码并将其留在那里的做法非常我自己讨厌这种做法。
但这就是我所处的情况。几个月前，我作为软件开发人员加入了一家公司。我在公司工作了几个月作为实习生，大约在最近加入前一年。我们公司使用源代码版本控制（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中不合适。如果包括标签在内的任何内容不合适，我会提前道歉。
答案 0 :(得分：1)
如果来自另一个项目的某些文件的副本真的意味着（对于这个来源）“分歧点”和源和分叉的并行独立进化，那么遗留历史和注释代码实际上是“白噪声”并且可以很容易地消除在你身边。对于未来可能从父母提及“分叉点”的传播，只有在修改历史的第一行，即smth。像
...
* Date Version Modified By Description
* 2012-10-25 1.0 ADTC Created from 12.34 of <filename>
...
提问者补遗（ADTC）： 除了上面的答案之外，我还想引用一条评论。
[...]获取源代码，删除与谁做（历史评论）相关的评论，但保留关于源代码/类/方法做什么的评论 （信息性评论）。这就是评论部分应该是什么。它应该清楚地定义方法正在做什么，如何实现它以及在什么条件下抛出异常。 - Wins，2012-10-25 00:57:57Z
答案 1 :(得分：1)
如果我是你的职位，我宁愿修改其他源代码，并将其作为我的项目中使用的库。
答案 2 :(得分：0)
我建议您自己使用一些版本控制 - 我建议使用git。有一个“上游”代码分支，与您的高级同事目前拥有的任何内容同步。然后，您可以为您的工作分配一个或多个分支。您将很好地了解使用git diff对“上游”分支所做的更改，您可以搜索您在该项目上所做的所有事情的历史记录等。这一切都是自动的，无需手动代码版本控制，文件总是“干净”，所有历史都在git中提供。