我目前正在通过添加一些新项目并将两个旧存储库中的旧代码和数据合并到本地Subversion存储库中的过程。

过去，我通常将遗留代码放在专用的"旧版"文件夹中，以免"干扰"新的"结构合理"的代码树。但是，本着重构的精神，我觉得这有点不对。从理论上讲，遗留代码将随着时间的流逝而重构并移至其新位置，但是实际上这种情况很少发生。

我们如何对待旧代码？尽管我很想将旧的罪恶藏在"旧版"文件夹中，但再也不想再看了，在某种程度上，我希望通过强迫它生活在存储库中更"健康"的居民中，也许是遗产代码有一天会变得更好的机会？

(是的，我们都知道我们不应该重写内容，但这是我的"有趣"存储库，而不是我的业务项目...)

更新

我不担心跟踪各种版本的技术方面。我知道如何使用标签和分支。这更多的是心理方面的，因为我更喜欢在存储库中使用"整洁"的结构，这使人类浏览起来更加容易。

解决方案

回答

在Subversion中，标记是非常便宜的操作。开始重构时以及在进行过程中的常规阶段，请标记代码。这样，仍然可以轻松访问旧代码(但功能代码)作为闪亮的新代码(但代码损坏)的参考。 :-)

回答

有一天所有代码都变成了"旧版"，为什么要完全分开呢？源代码控制按项目/分支或者项目/平台/分支以及这种类型的层次结构进行。谁在乎牙齿多长时间？

回答

就像使用第三方存储库一样，使用外部定义(svn：externals属性)来引用旧代码。

然后，我们可以将重构工作与从属项目分开，并(使用固定的修订版引用，即-r1234)非常明确地说明从属项目所依赖的旧版代码的修订版。

回答

这是免费心理分析：

我们在这里拥有的根深蒂固的愿望是修复遗留代码，以使其不再成为遗留代码。当我们将其隐藏时，我们只是在压抑这种欲望，试图避免它，因为这是一种不舒服的感觉。如果我们将其遗忘在外，将会发生以下两种情况之一：最终将使我们疯狂，并使我们不得不自杀，或者(更乐观的是)，我们会想起每一个凌乱的时刻，直到我们最终分解并清理干净。

不要掩藏混乱。打扫。否则，迟早会再次咬你。

回答

这取决于我们所说的遗产。如果说传统，意思是"来自某个已退休应用程序的代码，这太糟糕了，我们将不再使用它"，则应将其与当前代码分开。
如果它是我们当前项目中的东西，但是是由其他人编写的，或者不符合我们当前的标准，则只需对其进行常规处理，然后将其标记为将来在问题跟踪器中进行重构。