Noooooooooo, please please don't... Method history is so much more useful than 20 extra MB's on my HD :S
This is /not/ a dichotomy. For my image I wrote a condenseSources that preserves history. It edits out duplicates, and cuts off branches in the history that lead nowhere. So at the end you get all the versions of each method that are ancestors of the current version. I can email you the code and you could consider making it the default. Let me know.
Cheers, Henry
-- best, Eliot
What about having a changes file per release? Each .changes file records its predecessor file - including md5checksum. The search just parses multiple files. .changes.1.0 .changes.1.1 .changes.1.2 .changes.current
In theory, anyone can decide on an individual basis how far back to keep history. An image could be shrunk for a client deliverable but easily added back in to troubleshoot the client's live image.
ideally we would love to have a little db can branch to existing one or distributed one and keep all the non redundant changes. Now it requires a lot of work. Stef