This was very straightforward in Buildbot but seems impossible in Hudson. I propose that well-formed Subversion projects (having directories trunk, tags, and branches) be supported better in that a change would trigger a build whether it's on trunk or on any branch, and the exact relative path be saved in a designated build variable. This would eliminate a lot of parameterization for builds and stop rewriting of jobs from trunk to branch X and back. Things like release branches and feature branches are very common and supporting them in the standard Subversion plug-in would be a proper thing to do, especially because Subversion project recommends trunk/tags/branches structure for many years in their book.

Currently, one enters just repository URL, e.g. http://host/repo/trunk. Then, to switch to a branch release1, one needs to either copy the job, or make the change in place, and replace repository URL with http://host/repo/branches/release1. I propose that instead, Repository URL to be entered is http://host/repo (no trunk etc.). Additionally, two parameters with easy default are introduced:

• Relative path for trunk: trunk} by default but can be changed;
• Relative path for branches: branches by default but can be changed.

Any change detected in the tree would then be easily assignable to a particular subtree, and one (or more) builds would be started for each subtree such as trunk or branches/release1.

I don't know Hudson internals at all but ideally a notion of branch should become explicit if it's not so already.

Looking a bit into the future, the same can be easily supported in Mercurial because the branch name is part of a commit. It would actually be easier in Hg because, unlike Subversion, it doesn't have a concept of committing into trunk and branch in one action, whereas in Subversion a commit touching multiple directories under http://host/repo from my example above will not be stopped.

Git would be more problematic because branches there are very different from Subversion or even Mercurial.