On Sun, Mar 16, 2008 at 10:00:13PM -0700, Paul G. Allen wrote:
I've used version control in every place I've worked. It's always been far faster if I can see the reason for the code change right in front of me instead of using the version control system to study the differences. It takes time to switch from the IDE or editor to the version control system, lookup the change, study it, then switch back to the editor.
But why fix the problem in the wrong place. If the revision control system doesn't work well, it should be fixed.
Often the changelog in the version control system (probably the same one that's at the top of the source file) is not adequate either, especially in code that's many years old, has gone through many changes, and has a revision list as long as your arm.
Again, don't clutter my source because your version control system isn't very good. The Linux kernel has a very long revision history. I've never had problems tracking down changes to drivers made by random developers years ago. I couldn't imagine doing anything resembling that based on a few meaningless comments in the source.
With embedded systems, there's almost always a reason to care what the code was like even years before. Often it's because a customer has one of those older versions and needs support. Other times you find you want a piece of code that performed a function that was removed, and now it's needed again.
I sure hope your code isn't cluttered with ifdef'd or commented out code.
Why should PCs and other software be different? (I honestly can't think of a good reason. Personally, I like to know the entire history of a project and all revision levels from day one.)
Yes, I agree, just don't put it in the source. Dave -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
