use make and version control system for every project?

Cameron Laird claird at lairds.com
Wed Oct 8 13:18:52 EDT 2003


In article <m3vfr2fus7.fsf at ieee.org>,
Jorge Godoy  <godoy at metalab.unc.edu> wrote:
>Carl Banks <imbosol at aerojockey.invalid> writes:
>
>> Why is that important?  How often do you really need to know when a
>> bug was fixed, for example?  (I'm serious.  I've never needed to know
>> these things.  Do other people really use these features for personal
>> projects?  And if they do, is it really that often?)
>
>Maybe your client calls you and says that the program is not working
>as it should and say that he doesn't know the number of his version
>immediately, but he remembers it was installed one or two weeks
>ago... You remember solving such a bug, but when? 
I'm skeptical about claims of such use cases.  In the
'80s and before, we heard a lot of things on the order
of:  "what if the user comes back and says he needs
this error fixed immediately, but only this one error,
and nothing else can change?"  Well, yes, if accomoda-
tion of such incidents, or even the more plausible one
Mr. Godoy describes, is a requirement, then, yes, 
there's good reason for all that functionality source-
control systems offer.  

My own view is that those scenarios were only signifi-
cant for a brief interval, when our cost structure of
installed-software vs. developers vs. hardware vs. ...
hit a neighborhood we'll never again visit.  I don't 
doubt *at all* that people are still saying these 
sorts of things; Mr. Godoy's example is quite apt, in
that sense.  The correct solution to it, though, lies
more in the plane of customer relations.

How often "do you need to know when a bug was fixed"?
Often, still; it certainly arises.  For the most
part, though, in 2003 there's a healthy emphasis on
making what's right in front of us--the current 
version--correct, rather than just "fixing bugs".
'Least, I like to think that.
			.
			.
			.
>To me, 'few = 0', but to you it might be 'few = 1' or more... This
>varies from group to group too. We had a team that worked synced and
>that could have 5 developers working very fine just by themselves, but
>another team required a version control system for just 2 of
>them...
>
>Revision control systems are not a substitute for project management
>and meetings. 
Worth repeating.  I'm fond of version control, 
although not because of customer demands to
look backwards as seems to be true for others.
			.
			.
			.
-- 

Cameron Laird <claird at phaseit.net>
Business:  http://www.Phaseit.net




More information about the Python-list mailing list