Josef Wolf wrote:
>On Wed, Jun 19, 2002 at 02:59:38PM -0500, Karl Fogel wrote:
>
>
>
>>This method is the very heart of concurrent versioning, at least as
>>implemented by CVS and Subversion. The situation you describe could
>>happen, but in real life, Sam would check to make sure that the
>>exported release works, and Bob and Joe would use a little common
>>sense.
>>
>>
>
>In real life people are not perfect (maybe you are, but I am
>definitely _not_) and make mistakes purposeless. ;)
>
>
>
>>If you haven't used CVS in a concurrent development environment much,
>>you might not realize what a non-issue this is in practice (but I
>>*would* suggest giving it a try before assuming the model doesn't
>>work.. :-) ).
>>
>>
>
>I am using CVS for 10 years now. Because of that I know that some
>aspects of it are error prone. In real world errors happen when you
>are in a hurry.
>
I understand your point, but the fact is that _no_ tool can help you
avoid the problems caused by bad management. For example, even if
Subversion warned Joe about Bob's changes, it won't stop Sam from
picking up a snapshot before Joe's commit. Yes, the tarball will
compile, but Joe's bugfix won't be in it.
Release management is much more than just using version control tools.
The scenario you describe couldn't have happened on my project (which
uses CVS, too), because we put safety checks in the release process that
are designed to prevent exactly such problems. (One such check might be
to compile and test every tarball _after_ it's been created, but
_before_ it's released).
Sure, anyone can circumvent a process, and anyone can trick a tool (want
to know how to make Subversion believe the working copy is up-to-date,
even though there are changes? It's very easy). Preventing that is not
the version control tool's job. It's the project or release manager's
job to make sure that people a) understand the process and the reasons
for it, b) "buy into" the process -- i.e., agree it's a good thing to
follow it, and c) actually follow it.
Being in a hurry is no excuse for making mistakes. You should have
foreseen that you may be in a hurry at some point, and acted to prevent
it. Yes, planning is part of quality assurance! If worse comes to worst,
it's always better to be a day late than to ship a useless product.
(Note to self: Really, I never could understand why people insist on
saying "QA" when what they're really talking about is testing, i.e.,
quality _control_. QC is part of QA; so's planning, project tracking,
reviews, etc. etc. etc.)
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 20 00:50:28 2002