A little 'off topic'-this is really a configuration management question,
but thought someone who monitors this list might be able to help ...
We are using Subversion to store our 'gold master' production runtime
images (in addition to tags back to source code, etc.). We are
integrating various runtime components from distributed development
teams and once we have cleared preliminary QA, we stored the integrated
image in Subversion and tag it. From a configuration management
perspective, this system is working well.
However, between two builds of the same identical source code (or so we
believe), some .NET assembly DLLs will show changes in their binary
image causing Subversion to detect a modified file and include it in the
next commit. Introspecting the binary image of the assembly DLL reveals
that in fact, there are only about 4 bytes in the assembly DLL that have
actually changed and the assembly DLL is otherwise functionally
identical to the previous version.
I'd like to eliminate this behavior so that only .NET assembly DLLs
which have substantively changed are committed to Subversion. A typical
culprit in these cases are changes in the AssemblyInfo.cs files, but I
have reviewed these and do not see any changes or wild cards.
Has anyone else ever wrestled with this issue and might be able to
provide some ideas, tools or pointers for managing this problem? My
goal is that any given runtime image change set (Subversion commit)
contain only those .NET assembly DLLs that have substantively changed,
but not include those that have benign differences which arise simply
from recompilation.
Thanks,
Ken Parrish
Gomez, Inc.
Received on 2008-08-04 17:00:35 CEST