How do you treat legacy code (and data)?

Question

I am currently in the process of restructuring my local Subversion repository by adding some new projects and merging legacy code and data from a couple of older repositories into it.

When I have done this in the past I have usually put the legacy code in a dedicated "legacy" folder, as not to "disturb" the new and "well-structured" code tree. However, in the spirit of refactoring I feel this is somewhat wrong. In theory, the legacy code will be refactored over time and moved to its new location, but in practice this rarely happens.

How do you treat your legacy code? As much as I feel tempted to tuck away old sins in the "legacy" folder, never to look at it again, on some level I hope that by forcing it to live among the more "healthy" inhabitants in the repository, maybe the legacy code will have a better chance of getting well some day?

(Yeah, we all know we shouldn't rewrite stuff, but this is my "fun" repository, not my business projects...)

Update

I am not worried about the technical aspects of keeping track of various versions. I know how to use tags and branches for that. This is more of a psychological aspect, as I prefer to have a "neat" structure in the repository, which makes navigating it much easier—for humans.

Answer 1

All code becomes 'legacy' one day, why seperate it at all? Source control is by project/branch or project/platform/branch and that type of hierarchy. Who cares how long in the tooth it is?

Answer 2

Tagging is a very cheap operation in subversion. Tag your code when you start refactoring and at regular stages while you go along. That way it's easy to still access the old (but functional code) as a reference for your shiny new (but broken code). :-)

Answer 3

Here's your free psychological analysis:

What you have here is a deep-rooted desire to fix your legacy code so that it's not legacy anymore. When you hide it away, you're just repressing that desire, trying to avoid it because it's an uncomfortable feeling. If you leave it out in the open, one of two things will happen: it'll eventually drive you and insane and you'll have to kill yourself, or (more optimistically), you'll be reminded of each messy bit over and over until you finally break down and clean it up.

Don't hide the mess; clean it. Otherwise it'll come back to bite you sooner or later.

Answer 4

It depends on what you call legacy. If by saying legacy you really mean 'code from some retired application which is so bad we'll never use it any more' it should be separated from you current code. If it is something from your current project but is written by other people or is not up to your current standards just treat it normally but flag it for re-factoring in the future in your issue tracker.

Answer 5

Use Externals Definitions (svn:externals property) to reference your legacy code as you would a third-party repository.

Then you can separate your refactoring work from your dependent projects and (using fixed revision references i.e. -r1234) be very explicit about which revision of the legacy code the dependent project depends on.