??? 08/06/10 15:52 Modified: 08/06/10 16:12 Read: times |
#177795 - Thats a good point, but Responding to: ???'s previous message |
that really only works when you have limited hardware under your control or limited clientèle. If you make a hardware change and you release a new version of embedded code, you can only support the people who have recently bought from you if you do not keep back logs in some fashion. Either way, you can only support the old for so long, but a good company should support their customers for quite some time. For example, Microsoft supported Win98 for a very long time, but the hardware evolved beyond a reasonable point to keep the software going. In this sense, I am in agreement about how often to save your work changes. Saving every second just does not make sense because you find yourself consuming your time with organization. If you have a clean desk, you're not doing any work! Also, looking at what you've last changed may lead you down the dark path. I would say take a careful look at the last change, but do not assume that it is the problem because it may just be a symptom of a greater underlying problem. As Andy points out in his contradicting reply
Andy Neil said: Even when it isn't the "new" code itself that's wrong - just its effect on (buggy) "old" code - knowing where the changes are is still useful in focussing the debug attention. |