The hudson ivy plugin seems to compute upstream and downstream project
dependencies based only on an ivy organisation and module name match. The
unpublished (resolvable) ivy files configured in a project's post-build action
may specify an optional revision attribute in the module info element. This
attribute, if specified, can be used as an additional datum for more fine
grained revision matching to determine upstream and downstream project
dependencies. This could help reduce unnecessary builds.

For example, consider a Hudson project with a resolvable ivy file with the
following info attribute

<info organisation="myorg" module="mymodule" revision="trunk"/>

Consider also that there are two other Hudson projects respectively declaring
the following dependencies on the myorg/mymodule module

Project 1
<dependency org="myorg" name=mymodule" rev="trunk+"/>

Project 2
<dependency org="myorg" name=mymodule" rev="branch+"/>

If Hudson successfully processes a project build of the myorg module, the
behavior of the current Hudson ivy plugin would be to trigger a build to both
downstream projects 1 and 2. However the resolvable myorg ivy file in the
upstream project indicates that it is revision trunk. Therefore by the rules of
standard ivy revision pattern matching, only project 1 should be recognized as a
downstream project dependency and thus only a project 1 build should be
triggered. I believe the Ivy API should include algorithms that could help with
the pattern matching logic.