Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When is it okay to delete?

...destroy?

When should you never delete/destroy no matter how old (ie. health-management software?)

share|improve this question
add comment

closed as not a real question by gnat, Kilian Foth, GlenH7, Giorgio, Karl Bielefeldt Apr 18 '13 at 21:49

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers

up vote 5 down vote accepted

What do you mean by "delete"? If you just want to remove files form the current HEAD (what the most recent version is called in most source control systems), go ahead. Most source control systems are designed to handle file deletions.

Indeed, once it is in the history, some source control systems make it very difficult to actually remove things form their history. If you have added a file that you want to remove, it is usually just easier to delete the file and do a commit with the file removed.

This is generally a good thing. You never know when you may want to get access to old code. The space requirements are usually not significant unless you have a huge number of large commits. As @nonnb says, you also may need it for audit and compliance purposes (e.g. ISO27001).

The only case when something should be removed from the revision history is when something sensitive has accidentally been committed, such as a private key, password, test data that contains real customer information or data that potentially breaches privacy regulations (PII).

share|improve this answer
    
+1 for mentioning genuine reasons for deletetion like legal requirements –  MarkJ Sep 7 '12 at 12:34
add comment

Just to be clear, I'm assuming that by 'destroyed' you mean permanent deletion of all versions of the file, versus just removing a file from the current branch.

IMO, valid source should never be destroyed. The only time anything needs to be deleted from a repository (at least, in any ethical situation) is if the file shouldn't have been there in the first place, e.g. accidentally adding compiled artifacts like obj, bin, pch etc into the repository.

Rationale is:

  • Audits - finding out who changed what, when and why can be critical to getting to the bottom of an issue, and determining the impact of a bug on a customer base even after years have passed (and 'proof' can be a job saver when it comes to the blame game, unfortunately)
  • Asset - remember that source is a company asset, which may need to be transferred if your company is sold, merged etc. Destroying old versions of source could be viewed in a dim light by bean counters, who won't be in a position to understand your argument that the code isn't relevant.
  • Size - Files in a VCS are usually compressed, so there isn't much incentive to delete to free up space etc.

A typical solution for removing source code from a project which is no longer wanted is to move it or archive it, although this is largely unnecessary in contemporary source control systems. (e.g. CVS has an attic)

share|improve this answer
add comment

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