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.
.
.
.
