Brane wrote:
> This is one of the QA nightmare scenarios:
>
> QA: Hey, we found a bug in the release bits. Here's the repro.
> Dev: Sorry, can't reproduce your error, I hit an assert as
expected.
> QA: So test the release version!
> Dev: Uhuh. We don't do that.
Message to Dev: you *will* test both the debug and release versions. It
is designed that way, it is intended to catch different classes of
defects.
The Dev hit the assert (uh, "as expected"?!) According to what I've
learned on this topic in this mailing list that means that something
that should never occur has occurred. And as I have been told, that
means that something is "WRONG" and must be fixed. The Dev couldn't
reproduce the QA's error because he produced another error first, and
one which was designed to let the Dev know that something Really Bad
(TM) happened. Great. Fix the condition that causes the assert, then
retest and see if the QA error still exists, and then fix that. Case
closed. Book him, Danno.
> Another common difference between debug and release versions is that
the
> latter doesn't contain debug information.
Arguably common, but certainly not required. See, for example,
"Generating and Deploying Debug Symbols with Microsoft Visual C++ 6.0"
[1] for creating debug symbols for release builds. I've known other
C/C++ compilers to support this sort of thing, I assume it is a fairly
widely available feature.
Reiterating from my previous post, the fundamental difference between
release and debug builds is whether optimization is performed or not.
When the compiler (e.g.) is allowed to inline a function, that makes
interferes with debugging activities like setting a breakpoint in the
function.
So I am confused: are people saying that Subversion is never compiled
for release? Wouldn't that mean that compiler optimizations are not
performed? If so, what would justify that?
Cheers,
Stuart
Stuart Celarier | Corillian Corporation
[1] http://msdn.microsoft.com/library/en-us/dnvc60/html/gendepdebug.asp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 23 09:45:10 2006