22 Jul
2025
22 Jul
'25
3 p.m.
On Mon, Jul 21, 2025 at 6:26 PM josh <joshnatis0(a)gmail.com> wrote:
On Monday, July 21, 2025, Chet Ramey via COFF
<coff(a)tuhs.org> wrote:
code
control and configuration management. The first change tracking
programs such as SCCS and DEC CMS tracked changes on a per-file basis. If
a change set involved more than one file, you had to track that information
elsewhere. Later change tracking systems added the concept of a change set.
On 7/21/25 11:27 AM, Paul Winalski wrote:
Does anyone else feel like this is still an unsolved problem?
Yes. Change tracking is just one facet of the larger problem of source When writing all but the most trivial bug fixes I
always put in a
comment referring to the bug report number. This helps with what can
otherwise be a perplexing problem: "why is this bit of code there?"
I put those in the change log entries.
There is a lot to say about a change which would be
extraneous to include
in the code as comments — real-world context (as mentioned), trade-offs
considered / why specific implementation decisions were made, explanation
and annotation, potential future steps, testing/validation, and even rich
media demonstrating things that may be hard to express in text.[1]
In the shops I've worked at we used our bug-tracking system for that. At
DEC
we created pseudo-"bugs" in the tracking system for new development.
That way all of the information about what was changed and why was in one
place.
-Paul W.