From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Eric J. Holtman Sent: January-28-11 8:56 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] What's happened to Ryppl?
On 1/28/2011 7:46 AM, Edward Diener wrote:
I do not follow why these are advantages. I can make any changes locally for files using SVN without having to have a connection to the SVN server. Your phrase "incremental local commits" sounds like more Git rhetoric to me. How does this differ from just changing files locally under SVN ?
You can check in while you work. Which means you don't have to worry about "breaking the build", or anything like that.
Write some code, test it, seems to work, check it in. Come back after lunch, discover it's fubar, revert. Lather, rinse repeat.
This may be adequate IF you're working alone and if you have all the time in the world, but it will become an unmaintainable nightmare when the number of programmers contributing to the project increases significantly and as time pressures grow. Imagine the chaos that would result from this if you had a dozen programmers doing this independantly to the same codebase. And actually, I don't care which version control software is in use, as long as it is used well. Each product has strengths and weaknesses, and thus some will have strong preferences for thos eproducts that most closely reflect their own tastes. Unless a given product's developers are blithering idiots, a rational argument can be made for using their product. And then, the final decision is made either by the team, democratically, or autocratically by a project manager or team lead. And if a change is to be made, the onus is on the proponents of the change to first prove the change is wise and then to provide/plan the means of making the change. It is folly to decide to make a change, even if to a demonstrably superior product, if there are insufficient resources (including time) to get it done; especially if the existing setup is working adequately. A practical rogrammer, while having preferences for certain tools over others, will be flexible enough to work with whatever is in place for a project to which he has been assigned to contribute (in a commercial setting) or to which he wishes to contribute in other cases. As one responsible for a small development team, and who has to keep junior and intermediate programmers on track, this notion of " Write some code, test it, seems to work, check it in. Come back after lunch, discover it's fubar, revert. Lather, rinse repeat" scares me. When you're dealing with a commercial app that has half a million lines of code, or more, it is just too easy to break things (there are practical and commercial reasons for rational modularization as results in object oriented programming, as well as proper management/design of compilation units, &c.). I would prefer a model where there is a highly developed suite of test code (actually, I find it is often best if one begins with the tests first - but sometimes that is not practical), unit tests, integration tests and usability tests, and nothing gets checked in unless the code base plus the new code not only compiles, but the developer can show that with his implemented changes, the system still passes all tests. And note, his new code must come with a test suite of its own, and must pass through a code review before we accept that his tests are adequate and thus before he can run the full test suite. With this model, it happens that new code stresses existing code in initially unexpected ways, revealing previously undetected bugs. But at the same time, it makes it less likely that new code will introduce a significant number of new bugs when it is approved to be commited to the codebase. And this means that while the new code that is approved to be commited will have the same number of bugs per thousand lines of code that most other programmers experience in their code, the number of bugs per thousand lines of code can only decrease. And where the version control software in place does not support a given detail of this model (and note, this model can be made to work even with something as primitive as RCS or CVS), we need a manual process to make it work. In my practice, no member of my team commits anything until we know it works with everything already in the repository - no exceptions. This means that sometimes a programmer will work on an assigned task for days, or even a week, without commiting changes to the repository. This actually help productivity rates since we waste much less time tracking down bugs that had been introduced weeks or months earlier, and then fixing them along with new code that unwittingly depended on code that was broken. Until I learned this, I occassionallt saw situations where weeks or months worth of work had to be discarded because of dependancies within code along with months old code that had subtle bugs (but then, I have been doing this for 30+ years in a number of different languages, and the commercial practice of software development wasn't then what it is now). Cheers Ted