我目前正在通过添加一些新项目并将遗留代码和来自几个旧存储库的数据合并到其中来重组我的本地 Subversion 存储库。
当我过去这样做时，我通常将遗留代码放在一个专用的“遗留”文件夹中，以免“干扰”新的和“结构良好”的代码树。但是，本着重构的精神，我觉得这有点不对。理论上，遗留代码会随着时间的推移被重构并移动到新的位置，但实际上这种情况很少发生。
你如何处理你的遗留代码？尽管我很想将旧罪藏在“遗产”文件夹中，再也不会看它，但在某种程度上，我希望通过强迫它生活在存储库中更“健康”的居民中，也许是遗产代码有一天会更好地康复吗？
（是的，我们都知道我们不应该重写东西，但这是我的“有趣”存储库，而不是我的商业项目......）
更新
我不担心跟踪各种版本的技术方面。我知道如何为此使用标签和分支。这更多是心理方面的，因为我更喜欢在存储库中有一个“整洁”的结构，这使得导航更容易——对人类来说。
有一天，所有代码都变成了“遗留”，为什么要分开呢？源代码控制是按项目/分支或项目/平台/分支以及那种层次结构。谁在乎它的牙齿有多长？
标记是颠覆中非常便宜的操作。在开始重构时以及在进行过程中的常规阶段标记您的代码。这样，仍然可以轻松访问旧的（但功能代码）作为您闪亮的新（但损坏的代码）的参考。:-)
使用外部定义（svn:externals属性）来引用您的遗留代码，就像您使用第三方存储库一样。
然后，您可以将重构工作与依赖项目分开，并且（使用固定修订版引用，即 -r1234）非常明确地说明依赖项目所依赖的遗留代码的修订版。
这是您的免费心理分析：
您在这里拥有的是一种根深蒂固的愿望，即修复您的遗留代码，使其不再是遗留代码。当你把它藏起来时，你只是在压抑这种欲望，试图避免它，因为这是一种不舒服的感觉。如果你把它放在外面，两种情况之一会发生：它最终会让你发疯，你将不得不自杀，或者（更乐观地），你会被提醒每一个混乱的部分，然后直到你最终分解并清理它。
不要隐藏混乱；打扫。否则它迟早会回来咬你。
这取决于您所说的legacy。如果说遗留您的真正意思是“来自一些已退役的应用程序的代码，它非常糟糕，我们将永远不会再使用它”，那么它应该与您当前的代码分开。如果它来自您当前的项目，但由其他人编写，或者不符合您当前的标准，请正常对待它，但将其标记为将来在您的问题跟踪器中重新考虑。