At our company, we have a single version control repos with a structure like this:


After almost two decades of development, this list has become long and confusing, mixing active projects with those long dead. Orientation is difficult for newcomers. We are discussing two options.

Delete old elements:

  • Makes clear this is never to be touched again.
  • Everything is, of course, still retrievable through version control.

Moving old elements to an 'archive' folder:

  • Out of sight, but still in reach.
  • For some, this is not good enough.

How can we improve the clarity within our repos?

  • 1
    I think this SO question answers yours. The repository for old code should be source control repository. Only keep code commented if you know for sure you'll be needing it very soon (e.g. You put a quick fix in place and comment the failing code cause you know will come right away fix the code you just commented)
    – Laurent S.
    Jul 16, 2015 at 9:29

2 Answers 2


The problem with deleting is that they are "out of sight" and therefore "out of mind". The problem with archiving is that links or relative references will no longer apply. Tricky...

Personally I would delete them, and tag the revisions that these were deleted. This allows the dead projects to be easily retrieved, in place, yet also be hidden but still known about. Add a description for each of the dead projects so someone knows what they did, if they do decide to look for old code to resurrect or build from.


Since the history is preserved in version control, there is absolutely no reason not to remove code you don't need. By the way, this applies as well to commented code within the source: don't comment blocks of code, just remove them; if you'll need them later, version control is your friend.

Later may be even in an hour. The common sense may dictate that if you think you'll need a whole project or a piece of code in an hour, then it's better to keep it or comment it. I would discourage such practice, since reverting removed elements should be a matter of seconds anyway (especially since you remember exactly what was removed). Moving project to archive directory, and then moving it back will take the same amount of time then reverting. As for the commented code, there is a huge risk that you'll end up forgetting to remove it if it appears that you actually don't need it.

Removing entire projects is especially important for persons who join the project. In SVN, for example, the new person has to checkout the last revision to get the source code, which means downloading even archived projects. This can impact the time wasted doing the original checkout, time you can considerably reduce by simply removing the projects you don't need, instead of moving them to a specific directory.

To ensure optimal performance of your team, make sure that:

  • The version control history will remain forever. I've seen many cases where teams migrate to a different version control and don't bother migrating the history (although it's relatively easy to do). There was also one case where the team decided to remove the old revisions to free some disk space on their server (yes, I know, you find that extremely stupid too).

  • Message logs are explicit enough and commits are granular enough to be able to quickly find the removed code when needed. Tagging might be used for that (although I'm personally against such usage, including in this particular case).

  • Developers, especially newcomers, know how to use history and how to get back the removed code properly. The worst case is someone who doesn't know how to do that and will copy-paste code by hand and then commit.

    The major problem with that is that version control doesn't know that the code already existed; this decreases the traceability (it's like all this code was written from scratch) and increases the disk usage footprint (since the version control should store the code instead of just referring to an older commit).

  • For deleted code, newcomers will hardly notice it ever existed. With archived code, they can browse and see what used to be there easily. Can we somehow achieve the latter while still deleting?
    – Hauke
    Jul 20, 2015 at 8:29
  • 1
    @Hauke: gbjbaanb suggested to tag the revisions. Since I'm personally against tagging, I would rather suggest having explicit commits (bullet 2 in my answer), as well as having a list (for example as a wiki) of all projects, including the ones which were removed. Jul 20, 2015 at 8:51
  • @MainMa Well, did you read the answer to your question? Because your issue with tags is a nonissue.
    – Andy
    Nov 14, 2015 at 2:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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