The “Implicit Backup” idea described in the previous chapter is a coin with two sides. Having lots of copies of the data does reduce the risk of losing that data, but it also makes it far more difficult to destroy.
Some version control systems have a way of actually altering the history of the repository. There are certain legitimate situations where we want to delete something and have it actually be deleted. In general, these situations arise when someone has a legal obligation to destroy all copies of some piece of data. It is insufficient to use the delete operation, since that doesn’t purge the data from the repository’s history. This feature is commonly known as “obliterate”.
Most version control tools do not support obliterate. It is generally agreed that the most important trait for a VCS is reliability. In the pursuit of reliability, anything which allows the history of a repository to be altered is at best a distraction and at worst, damaging. In many cases, any provision for the ability to obliterate things would cause the overall design to be altered in ways that compromise the performance and reliability of all operations.
As you can tell, I don’t like obliterate much. My company has been selling version control tools for over a decade, and our experience in providing technical support to our customers shows that obliterate is often misused. In my entire career, I don’t think I’ve ever found occasion to use obliterate. But I concede that there are valid use cases for it, and the presence of multiple repository instances does make things more difficult, so I mention it here.
With a DVCS, obliterating something would look roughly like this:
Get one repository instance Q which is complete. You’ll need to have every repository instance push everything to Q.
-
Clone Q while excluding the parts you want to obliterate. This requires that your DVCS support some kind of a “clone with exclude” operation.
-
Destroy all repository instances, replacing them with the clone you just created.
The difficulty of this recipe is determined primarily by the number of repository instances you have. With 10 instances, it’s probably not a big problem. With 5,000 instances, you’ve got a major task on your hands. Fortunately, the need to obliterate is extremely rare.
Or at least it should be. If your regular process involves a frequent need to obliterate, you should not be using a DVCS. In fact, my opinion would be that you should not be using any VCS in that kind of situation. You’re doing something that version control tools are not designed to do. You don’t need version control. What you need is something else, something that is not the subject of this book.