Tuesday, February 14, 2012

git diff: ignore the deleted files and newly added files

I have a project that has gone through some serious refactoring, during which a lot of garbage files were removed. Then during a code review, the HEAD was compared with the last release tag and bang!, BeyandCompare UI was popped up so many times that we had to abort it after a while.


git diff sha-for-pre-release


Then I though there must be a way to skip this and it turned out there is. When using git diff, there is an option, --diff-filter, among tons of others. And below are excerpted from the manual:


--diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]
Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type(i.e. regular file, symlink, submodule, …) changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B). Any combination of the filter characters (including none) can be used. When * (All-or-none) is added to the combination, all paths are selected if there is any file that matches other criteria in the comparison; if there is no file that matches other criteria, nothing is selected.


My favorite option is --diff-filter=MRT, which will skip added and delete files.

Saturday, February 4, 2012

Configurations of application using IoC, Spring.NET

I have being using Spring when I worked in Java world. Now that I'm in C# part of the world, I'd naturally go with Spring.NET. To be honest, before using Spring.NET, I did not even heard about StructureMap, Windsor, Autofac, NInject, let alone the Funq, Munq, Light.Core, etc. In general, I could live with XML configuration, and some configuration feature derived from XML really makes passing configuration data much easier, by putting below object definition in the container, you can isolate your often changed settings to a file without writing any glue code:

  <object id="SYSTEM.ConfigPropertyHolder" type="Spring.Objects.Factory.Config.PropertyPlaceholderConfigurer, Spring.Core">
<property name="LastLocationOverrides" value="true"/>
<property name="ConfigSections" value="config.app"/>
<property name="Locations">
<list>
<value>~/Config/config.app.xml</value>
</list>
</property>
</object>



now I can use a file named "config.app.xml", in folder Config, to hold my config settings:


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="config.app" type="System.Configuration.NameValueSectionHandler, System" />
</configSections>

<config.app>
<add key="value1" value="some data" />
<add key="value2" value="other data" />
...
</config.app>
</configuration>



and in the container definition xml file, I can use the settings defined in the config file:

  <object id="obj_id" type="type.name">
<constructor-arg name="para1name" value="${value1}"/>
<property name="pro1name" value="${value2}"/>
</object>



And since most of Spring.NET's objects are defined with an id, there is even a further way to do the customization, using another class "Spring.Objects.Factory.Config.PropertyOverrideConfigurer, Spring.Core". Put such an object definition in container,


<object id="SYSTEM.ConfigPropertyOverride" type="Spring.Objects.Factory.Config.PropertyOverrideConfigurer, Spring.Core">
<property name="IgnoreResourceNotFound" value="true"/>
<property name="ConfigSections" value="config.system"/>
<property name="Locations">
<list>
<value>~/Config/config.sys.xml</value>
</list>
</property>
</object>



you gain the capability to directly change object properties in config.sys.app:

  <config.system>

<!--the key must be a <object_in_context>.<property>-->
<add key="obj_id.someProperty" value="12345"/>
<add key="another_obj.anotherProp" value="good!"/>
...
</config.system>



Ugly or not, it's really convenient and powerful. In general, Spring.NET is really a feature rich software package, not only a IoC container. And also the document is really good, comparing to most other OSS projects.

So what's the problem? The problem is I'm getting more and more tired with the angle brackets, and I would like to try something new, like NInject, Autofac.

Thursday, February 2, 2012

SubWCRev.exe and its dependencies

Our team is using Subversion as CVS, and thus it's natural to use SubWCRev.exe to retrieve source code version and embed into VersionInfo.cs file, so we can already rebuild the software when we get a bug report.

The problem is when the build process is running on build server, there is no TortoiseSVN installed on the server and I don't want to install it on all the build agents. So I took some time to find out the dlls that SubWCRev.exe depends on, in case I forget it:

# intl3_tsvn32.dll
# libapr_tsvn32.dll
# libaprutil_tsvn32.dll
# libsasl32.dll
# libsvn_tsvn32.dll