Hi Ken,
> 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.
Check for modifications in your source directories, use something like
svnlook dirs-changed (there may be a better command, explore the svn
toolset). After compilation - if changes are found in source then
commit/tag your assemblies, otherwise, revert the assemblies before
commit/tag. Should be trivial assuming you separate source code and
assembly output, non-trivial but do-able if you don't.
If you take this approach, it would probably be a good idea to work
with svn at a specific revision range at the time the compilation
takes place, in case someone sneaks in a commit. Of course that
depends on your build process and subversion strategy (stable trunk,
release branch, etc.)
cheers
si
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-07 07:20:32 CEST