Thanks for the detailed explanation, Eric. I'm now convinced. Martin
On 7 February 2011 22:20, Eric Shulman <[email protected]> wrote: >> 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. > > -- 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.
