> From a personal point of view I practically never look at source code > history, other than immediate history (that is the bit of history I've
> I personally find that there is no point in looking at history to > understand a bit of code, whether it is to fix a bug or implement a > new feature. > In my view source code history is a bit like credit card slips - you > look at this month's slips when you reconcile your credit card bill, > but never look at them again. > To me the desire to keep history is a bit like the desire some people > have to keep their old credit card slips: "Oh no, we can't throw them > away." While *some* users actively update all their TiddlyWiki documents each time a new TW core is released, there is an enormous collection of active documents whose core code is not regularly updated, and continue to use much older versions of the TW core, sometimes for *years* beyond the update. Of course, use of these older documents tends to fade as their codebase 'ages out'. When people encounter problems with these older documents, the usual recommendation is to first upgrade to the current TW core code to eliminate any bugs that have already been fixed by previous releases, and then see if the problem persists. Unfortunately, when people attempt to upgrade these documents, they often run into conflicts with their installed plugins, due to the extent of core changes that have occurred over time. Frequently, these conflicts have already been noted and resolved (usually by an update to the plugin code to work around the problems), and people can just update their plugins to match the current TW core and get back to work. However, if the problems *do* persist after updating all code, it then is necessary to dig deep into the core *history* to reconstruct the full picture of what has changed. Tracking changes to the core from release to release is often a very difficult process if you are not on the *inside*. I generally start by making a diff of old vs new core. Most of the time, when comparing the current release to the most recent previous release, the changes shown in the diff output are simple and obvious. However, while the diff does identify all the changed bits of code, it does not make it clear WHY things have changed, especially in code that has several bug fixes, made over several releases. It can sometimes be very complicated to figure out which changes are relevant to which fixes, particularly if it is just a line or two, buried deep in some other changes. SO... I go to the code history, and start working backwards. Unlike a simple diff, the history reveals the *connections* between code changes, not just the *existence* of those changes... particularly when the affected code is distributed across several different core functions. For example, if a core function get a new parameter, the *callers* of that function are updated to include that parameter, which can require even more code be added in the calling function in order to calculate a suitable value for the new parameter. I look at each and every changed function carefully, to consider whether it has impact on any of my existing code (i.e., my plugins). While this process is tedious, it is the only way that I have found to really *understand* the details of the changes. As far as *migrating* the history rather than simply freezing Trac... it is my opinion that using two different systems for reviewing code history will, despite people's best intentions to be diligent, inevitably result in information in the old Trac system being overlooked, forgotten, or simply ignored. To prevent this, all historical information should be included in the new GIT-based system so that there is one tool for reviewing all code changes, both from past releases and moving forward. -e -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
