A lot of the code I've been working on recently, both professionally (read: at work) and in other spheres (read: at home, for friends/family/etc, or NOT FOR WORK), has been worked on, redesigned and re-implemented several times - where possible/required. This has been in an effort to make things smaller, faster more efficient, better and closer to spec (when requirements have changed).

A down side to this is that I now have several code bases that have deprecated method blocks (and in some places small objects). I'm looking at making this code maintainable and easy to roll back on changes. I'm already using version control software in both instances, but I'm left wondering if there are any specific techniques that have been used by others for keeping the superseded methods without increasing the size of compiled outputs?

At the minute, I'm simply wrapping the old code in C style multi line comments.

I've added a C style example, simply because I'm more confident with the C style languages. I'm trying to put this question across as language agnostic (hence the tag), and would prefer language agnostic answers, if possible - since I see this question as more of a techniques and design question.

I'd like to keep the old methods and blocks for a bunch of reasons, chief amongst them being the ability to quickly restore an older working method in the case of some tests failing, or some unforeseen circumstance.

Is there a better way to do this (that multi line comments)? Are there any tools that will allow me to store these old methods in separate files? Is that even a good idea?

The author stated I'm already using version control software in both instances, so setting up another won't help much. I agree though. Keep them in previous revisions and don't worry about the current one.
–
Dylan YagaApr 3 '12 at 15:23

@DylanYaga yes, I have edited my answer. Good news is: he just has to start using it!
–
SimonApr 3 '12 at 15:24

I thought that this was the way to go, but I wasn't sure if there where any (for want of a better phrase) other ways to do this.
–
Jamie TaylorApr 3 '12 at 15:25

There's no benefit to keeping it, and no cost to removing it (if it really is obsolete). So, why keep it? To paraphrase some artist dude whose name I can never remember: your program is done not when there is no more code to add, but when there is no more code to take away.
–
TacroyApr 3 '12 at 16:45