Eliot Miranda wrote:


On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 20.09.2011 14:49, Marcus Denker wrote:
Hi,

The .changes have gotten really large... (32MB...)

So I will do a condense in the next update.

NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...

       Marcus


--
Marcus Denker -- http://marcusdenker.de


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.