views:

110

answers:

5

I've encountered this in multiple projects. As the code base evolves, some libraries, applications, and components get abandoned and/or deprecated.

  1. Most people prefer to keep them in. The usual argument is that the code does not really take any space, it can be left alone until needed again.
    So a repository slowly turns into a cesspool of legacy code, where it's hard to find anything.
    Another argument for keeping old code around is that new people will not be tempted to try to implement something that was implemented in the past, but didn't quite work out.

  2. Some people delete old code, since it creates clutter, raises more questions for new people, and you can restore any old snapshot of the code base anyway.
    However you can't always find the old code if you don't know where to look, as none of the (common) VCS I know offer search over the entire repository including all historical revisions, and the only way to search the old files is to check out the revision where the deleted file exists.

What would be a good approach to repository management?

+10  A: 
  1. Remove it. Its clutter - if it doesn't serve a point or is confusing, its better gone.
  2. git grep or similar.
Yann Ramin
+1  A: 

We have a branch that we copy stale libraries and projects to before deleting them from trunk.

repo
  +- trunk
  +- tags
  |   +- old-code
  |       +- project1
  |       +- project2
  |          ...
  +- branches

Though, to be honest, I can't really think of a time when we've actually gone back to an old project and resurrected it...

Dean Harding
+1  A: 

Branch the original code. Clean up the master/trunk and future releases.

The legacy code is there for whomever may or may not need it.

As far as searching for the file, I know git can do this. But in general you just search the commit logs of any repository

git log --all -- legacyfile

Then find the file in the branch:

git branch --contains $filehash

edit Just wanted to add that on several occasions I've had a need to go back and find files in other projects that were considerably old, 5 or 10 years or so. I was very grateful that it was still there.

jkyle
+3  A: 

Unused code does take up space in peoples' minds. Unused and unnecessary code clutters peoples' mental models and makes it harder to understand what everything in the repository is there for ("oh, don't worry about that, we don't use it anymore"). It is good to delete code from the repository in these circumstances, but it may be helpful to document (on a wiki or similar) what old applications/components/etc have been deleted, why they were deleted, and where they can be found.

David Johnstone
+1  A: 

In my personal Subversion repository, which is full of abandoned projects, I move things I don't want to see any more under an /attic directory. I could just as well delete them but, at the cost of one extra directory at the multi-project root, I don't have to go searching around history when I want to find something I thought I don't need any more.

Anonymouse