Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Typically when i work on a project i only go back a few days or the last major change when i decide to do something drastic.

I sometimes notice i broke a test or a feature and overlooked it for a few weeks so i may go back a month or two and see if the feature or test is broken and trace down the week i broke it. Then find what change did it.

On a long term project over the span of a year. Do you actually go back 6+ months and if so why?

share|improve this question

We started using CVS 10 years ago for our non-mainframe code, and I migrated the whole lot to git about 6 months ago. While mainly developing new things and maintaining existing versions, I have recently had to fix an unexpected issue in code put into production about 5 years ago. Being able to pull out the codebase from version control and merge in our new build system, allowed for a rapid fix and modernizing it too.

Many decisions in our codebase was made before my time. Being able to go back to see the code as it was then, with the comments, makes it easier to understand.

But, to answer your question - we want the complete history back to day one.

share|improve this answer
I second Thorbjørn: it is essential to keep history from day 1. You cannot predict when you are going to need it. But it supposes check in comments are sufficiently explanatory... – asoundmove Feb 26 '11 at 14:04
@asoundmove, why does it suppose comments are sufficiently explanatory? – user1249 Feb 26 '11 at 14:06
@Thorbjørn: does it not? In my mind if the comments are not explanatory enough you may as well look for a needle in a haystack, not even knowing whether there is a needle there. Comments are what guides you to find what you need (check-in comments should say why or what is being checked-in). – asoundmove Feb 26 '11 at 14:08
@asoundmove, I am still not sure what you comment upon. I am discussing how to look back on ancient versions to locate when a given snippet was added and in what context. Most VCS'es provide for seeing what version a given line was changed at. – user1249 Feb 26 '11 at 14:18
@Thorbjørn: Oh well, I'm showing how long since I used a VCS heh? But even with line number information, I have always liked to see the reason for a change in any given version. This can include a bug fix number, the reference to a new feature, maybe a proper specification or design document... I have found this to have been of great help when investigating ancient code. YMMV. Sometimes a given change spans several versions, the type of comment I talk about would allow you to trace through all those versions. – asoundmove Feb 26 '11 at 14:23

We still have the code of our years old versions. Because some customers swear by their ancient, tested programs and don't want to upgrade to our new versions.

So each time a major version is released we branch the old code. And the more important bugs are fixed in the current version plus in the older versions.

share|improve this answer

Where I work we can keep code in version control for a differing range of times. I guess it depends on the suituation you find yourself in.

We have some code in there for over 1 year (maybe 2 or more) and some for only a few weeks. The reasons for this are our customers use different versions of the system and we must be able to provide support and fixes for a minimum of up to 18/24 months after deployment, so we need to keep the different version branches available to meet this requirement.

Also we can spend several months, if not years developing new versions so we need to keep this code during the development process.

I know it's a vague answer but I guess the answer to your question is the amount of time code is stored varies from project to project and place to place.

But you should use source control where ever possible! It will save time and stress incase the worst happens. I also believe it would be better to keep code for too long than to remove it early.

share|improve this answer

Where I used to work, we had some very old version control - mid 90's I think, or something thatta'ways. Don't know when it started since (naturally) no one was interested in those parts, and true, it was in different control systems as time went by, but it was there.

The product is still being developed, and is still under VC. The "history available" in which most are interested is about two years (slow development cycle).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.