From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Eric J. Holtman
Sent: January-28-11 11:07 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] What's happened to Ryppl?
On 1/28/2011 9:59 AM, Ted Byers wrote:
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.
You proceed from a false assumption. You might have 1000 commits in your local copy. When you're done, and ready to publish, you "push" it as one.
No different than SVN.
So no pressing need to change from SVN
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.).
Again, no one sees your changes until your ready. It's there to help the individual. How often have you been in the middle of a large change to quite a few files, then said "oh, this sucks", and revert it. Then, a half hour later, you >decide "Oh, wait, 100 of those lines (out of the 1000 you just threw away) might be useful".
With SVN, you're hosed. With git, you're not.
Really? Anyone with any experience has faced this sort of thing countless times before, and even in the absense of software that makes handling this easy, have developed methods (often manual) to deal with it. Only a complete novice will not have figured this out and thus be so dependant on his software that he'd be "hosed" if he uses the 'wrong' software. But then, in a commercial setting, part of the role of the senior programmers/team leads/&c. is to teach their juniors so that they are flexible enough to cope with these situations regardless of the supporting software used. What I encourage among my team is to never throw anything away, unless it is demonstrably wrong. So, even with something as primitive as RCS, I/we wold not be "hosed". If git provides help with this, fine, but it is not essential. My practice has been to tell my team members they can use whatever tools they wish on their own machine. Some like Emacs, others vi, &c. Some like commenting out code that appears problematic while others include version info in temporary backups. I encourage them to work in watever way they find conducive to being as productive as practicable, as long as the code they produce works. The actual decision making process used can be rather complex, and is not simply a matter of comparing product feature lists in most cases. There is first an analysis of what development model is required. Then, we need an examination of features of available products and the extent to which each supports the development model selected. If the product to be developed is new, then one selects that product that best meets perceived needs (of course, this involves putting each of the products to the test to verify that each does what it says it does - it would be irresponsible to fail to put each option through its paces). If the project involves extending or refactoring an existing product, there is then an examination of the current state of that product and the software used to support it, along with everything that would be necessary to migrate it to use one or more new tools. And then there is the question of the implications for anyone else who works with the code. I would be quite annoyed if someone on some other team made a decision that forced me and my team to change some of the software or development processes we use because they adopted software that is incompatible with what we had been using. I have seen situations where one member of a team hyped one product (generally a commercial library), spending months developing new code using it, despite being repeatedly told of one or more deficiencies in it. His argument was that the product is the best on the market (with some support from the trade literature), and that he just needed a bit more time to figure out how to address the apparent deificiencies. After months had been spent (some would say wasted), he told us that there is no way to work around the deficiencies in the product and that we had to just live with them. I found a simpler product that DID meet all our needs, but it cost a few months to refactor the code to use the simpler product that, as limited as it was, met all our needs instead of the alleged 'best' product that did not, despite the fact that other aspects of it worked fine and that it had a huge number of features for which we had no need. The point, with an existing product, is that it represents a whole suite of decisions that had been made about design, and the various tools to be used to support it, and any decision to replace one tool (or anything else) carries costs that must be carefully evaluated and compared with alleged benefits. To illustrate, comparing software to manage task lists and meeting schedules, one has a wide range of products to examine from Google Calendar through open source products like SugarCRM, to the various commercial CRM products. At the one extreme, Google calendar is like a bicycle, with SugarCRM being like a 10 year old Chevy, and the commercial products more like a late model Mercedes. For some, Google Calendar is sufficient, and works well. For others (perhaps most) something like SugarCRM would be appropriate, and for others, with greater needs and deep pockets, one of the commercial offerings may be preferred. But, if you already have extensive data in SugarCRM, and you learn of a commecial offering that better meets your needs, migrating all your data from the one to the other will not be trivial, and may in fact make switching counterproductive, making hiring a PHP programmer to extend SugarCRM instead a more rational option. Please understand, I am not arguing the merits of git with you. Rather, I am pointing out you haven't made the case that a change to use it instead of SVN is either warranted or feasible or practicable. I have a number of products in svn, and if I am to be convinced to use any other version control software to manage their code instead of SVN, I'd need to be presented with an analysis not only of what each option (RCS,CVS,SVN,git,MKS, &c.) offers, but proof that each works as described, that the benefits of making a switch outweigh the costs, and a viable plan for making the switch. And all of this would have to be supported from well documented experience. An argument comprised simply of a claim that product 'X' is the best available because it does 'Y' does not even come close. Cheers Ted