Mike.Sullivan at sun.com wrote: > > >Who in the current process makes use of diff's in/attached to the CRs? > > People From The Future. And me.
They'd be better off not looking at unreliable data. Even if the alternative is painful but reliable. > >Why? > > perhaps when backporting a bug fix, or when trying to figure out > if the fix made broke something else. I was afraid the answer might involve backporting since that's the worst possible answer ;-( Whenever content (of any kind - here, code changes) is duplicated in ways that require manual intervention to keep them synchronized, it guarantees the 'forked' copies will go out of sync some of the time (in practice, most of the time). Computers do well automatically syncing N copies all the time, humans just don't. Hardly anyone can remember to go update N>1 copies of the same thing whenever one of them changes. Good intentions and all, it just flat out never works very well. When processes go against human nature, the process is broken. The authoritative copy of code changes is the one that lives in the source control revision history since that's the copy we're building and shipping. All persistent copies of diffs elsewhere (like in bug reports) cannot be trusted. If anyone is doing backporting using diffs from bug reports, they will be backporting subtly incorrect code a non-trivial percentage of the time. Don't Do That! (CVS has the same problem - we solve it by recording the set of files & versions in the CR. Unlike a diff, that info is immutable so you can reliably use it in the future to look up the diffs from the revision control system.) Danek Duvall wrote: > > Hopefully many of the reasons for this simply won't be necessary any longer > once we switch to mercurial, which keeps track of the entire changeset, so > you can always retrieve the diffs for any particular bug as long as you > have access to the source repo. Awesome.. when do we switch, anyway? The reasons to switch seem endless.. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
