This automatic rebase is a necessary operation to keep the feature branch usable after reintegration (see Keeping a Reintegrated Branch Alive).

In order to skip this rebase, the job for the feature branch should be disabled or deleted. Otherwise, the next rebase on the feature branch will likelly generate spurious conflicts.

In my opinion, if you don't want the automatic rebasing after reintegration you don't want to use the feature branch anymore. Am I correct ?

Hi,

Thanks for your comment.

Our use case is a bit different, because actually we don't use "feature branches" but "release branches". All the development happens on trunk and when we decide to release, we create a branch for it. All the changes made on the release branch (bug fixes) must be integrated to trunk, but as trunk might already contain the features that might not be ready for release, we do not rebase the release branch from trunk. Currentl we're doing that manually and svnmerge looked like a perfect solution for us. The only problem for us is the ability to prevent it from rebasing the release branch.

I was mistaken. Subversion 1.8 does not require the "keep-alive dance". So, it makes senses to add an option to use "Subversion 1.8 automatic reintegration merge" in the "Reintegration Action".

The plugin use svn merge with the --reintegrate option to replicate the feature branch changes back into the upstream branch. This requires the feature branch to be synced with the upstream branch (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#ftn.idp11155712).

This is not correct to use the plugin for a release branch.

If I understand correctly, you want to automatically merge every changes from the release branch to the trunk. As if the trunk was a feature branch of the release. You could use the plugin to do that (auto-rebasing the release to the trunk) but you will also have to make sure the trunk is never reintegrated to the release branch.

Maybe it would be simpler to add a svn merge from release branch as a pre-build step of the trunk branch?

Every release in our system has its own branch, used later for providing support for this version, so creating a prebuild step as you described would not be the best option, as we would need to merge more and more branches to trunk before running the build. Moreover, integrating the changes from release branch to trunk after release branch is change seems to be more natural than polling the release branch (in fact - all release branches) before each build of trunk.

I agree with Hugues that "rebase" after "reintegrate" is absolutely required, as per SVN documentation. However what would be nice here is an option to only do "rebase" on the feature job, without triggering the rest of the build.