| ??? 08/06/10 16:20 Read: times |
#177796 - Let a pro have good tools - don't worry about fools Responding to: ???'s previous message |
If a new version does not work find out why do not just go a revison back You don't go back to the previous revision because of a bug. You use the version control to check the age of individual source lines to figure out who/what/why - looking for where something broke. Only reason for throwing back a commit is that someone have seriously misunderstod something and starting to implement the wrong thing. One thing you can do with revision control software, is to park a bug fix or feature addition that does not work well. You can move these changes to a branch for later continuation, while you decide to make a release without the broked feature/bug fix. A lot of companies separates the main development from product releases, so they have one track where you add bug fixes (version 1.4.1 -> 1.4.2 -> 1.4.3) to already released software while you work with the new features that will be introduced in 1.5.1 or maybe the major rehaul of the software that will be released as 2.1.1. Or a specific customer may need a specific new feature for delivery next week but the next scheduled main release is two months away - so you branch the code and make a unique release for that customer, and merge that feature into the main development line to also be available when the next general release goes out two months from now. I have seen people spending 10 minutes on debugging rev n+1 and then giving up going back to rev n. There really are not bounds for how many stupid things you can see during a lifetime. But stupidity isn't relevant to how you can and should use tools. If rev n+1 contains an attempt at a bug fix you only roll back to rev n if you realize that you attempted the wrong fix. Don't keep a 100-line fix in one source file if you suddenly realize that a 2-line fix in another file would have been the correct way to go. Sometimes, it isn't obvious why something fails. That can result in a lot of wrong starts when trying to fix the bug. Most developers don't commit any code to the repository while working with the fix. They work with their own sandbox. Then they may notice that they have added printf() statements or other jump at unrelated places in the code. So intead of having any n+1 -> n, they just throw away some files and restores them to their original contents. After all, 95% of the time, the "best" bug fix is the fix that changes the fewest number of lines of code. It normally happens if the fix is closest to the true source of the problem. And it normally minimizes the number of new problems that may be introduced. Who is to say that what you did was not right, just badly implemented. Bad coding will be bad coding with whatever tools. All the tools can do is catch compile/runtime problems (compiler + lint) or help you get an overview of the current code and its history (repository and doxygen and similar documenting tools) Also, I have seen people spending an inordinate time analyzing what was changed, which will not tell you what is wrong. Good planning normally saves ten times as much time later down the line. If a change introduces a bug, there are two main alternatives: - the changes introduced a bug. - the bug was there but the changes the bug visibile. In both situations, it's very relevant to look at the changes made. But you can always find people spending their time looking at the wrong place. Bad programmers will be bad programmers with any tool, so they are not relevant for discussing good tools. One horrible incident was someone that for days backed out of n+1 till I intervened and found that the problem was not in the new code, but that some old routine was so badly written than any change in the area where the change was needed would make that other routine fail. One thing with "annotate" or "blame" or similar - viewing code history or viewing code with every single line tagged with date, developer and commit revision, is that functions that have large number of commits normally has it because the function is too complex. So there is a reason to look closer at the function and see if it should be replaced. But once more, your example hasn't anything with source code repositories to do, but with good or bad developers. Would he have been better at finding the bug if he hadn't had any source code repository but instead separate directory trees or zip files? When I manage, ther is a rule: "do not go back without permission" Irrelevant, since you use the history and annotate feature of source code repositories for "looking" at code. You hardly ever "go back" as in throwing away newer code, unless it is clear that the code is lousy. You may "go back" as in retrieving previous revisions (version tag or time stamp) for testing purposes. On one hand, you can quickly create a build from wherever in the time line. On the other hand, you can take old code and merge with specific fixes, to test assumptions. This may not be an important feature if the product has 2k of source lines. It may be invaluable if the product has 100k source lines. It's a tool in the tool chest, and you make use of it only if you feel it's a good tool for the specific problem. One thing with code repositories is that depending on size of organisation, you often add as step of code review. You have someone else look at introduced code changes, since a lot of bugs can be caught by just reading code. Having code reviews should catch code that is so broken that it deserves to be thrown away long before that code gets released. If the same developer regularly manages commits that should be thrown away, it may be time to figure if he can be used for something else within the organisation or if he maybe should find a new employer. A lousy developer will be lousy with any set of tools. You must see it from the reverse direction: a (reasonably) good developer can take great advantage of a more complete tool chest. No, his is NOT an argument against revision control, just an argument against the misuse. Everyting can be misused. The thing is that source code repositories comes almost for free. They do anything zip files can do. But they also add a number of new tools. There is no need to give people examples how hammers or screwdrivers or wrenches can be misused. They are still great and recommened tools to have available. Zipping or directory robs a developer from access to a number of great tools. But it is the individual developer who must decide when to make use of his extra tools - as long as he/she is allowed access to he tools. |
