RE: .NET assembly runtime images in Subversion ...

Ken,

I didn't see any response to this question. I am curious about the
statistics, but I believe the binary DIFF handles such minor changes
gracefully. You should only see 4 bytes of growth, plus overhead, when
you commit a binary that has 4 bytes of differences.

I hope someone here will correct me if I am mistaken. We also commit C#
Assemblies as dependencies in our projects. It sounds like you actually
commit assemblies that are built from your project's source, which
puzzles me.

If the assembly should not change, then it should not undergo a build.
I suspect you might be better off changing your process to end the
recompilation of those binaries. We only include shared libraries that
are versioned in their own "solution" in our application commits, and
only update those when necessary.

--
David
All developers are lazy as evidenced by the amount of time and effort
spent in making a computer do the work. 
________________________________
	From: Parrish, Ken [mailto:KParrish_at_gomez.com] 
	Sent: Monday, August 04, 2008 11:00 AM
	To: users_at_subversion.tigris.org
	Subject: .NET assembly runtime images in Subversion ...
	
	
	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.
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org