Re: [Boost-users] What's happened to Ryppl?

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2011-01-28 13:12:06

From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Eric J. Holtman
>Sent: January-28-11 11:07 AM
>To: boost-users_at_[hidden]
>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