Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-25217

Do not force automatic rebase upon successfull integration to upstream

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • svnmerge-plugin
    • None

      We want to make use of svnmerge plugin in Jenkins, especially it's feature of automatic integrations to upstream after succesfull build. We've discovered one issue which prevents us from using the plugin: we don't want the automatic rebase to be executed right after the integration. We realize that it is often convenient, but it would be great if there was a switch allowing to decide whether rebase should be performed during integration to upstream or not.

      The code where the rebasing is performed:
      https://github.com/jenkinsci/svnmerge-plugin/blob/master/src/main/java/jenkins/plugins/svnmerge/FeatureBranchProperty.java
      line 383

          [JENKINS-25217] Do not force automatic rebase upon successfull integration to upstream

          Hugues Chabot added a comment -

          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 ?

          Hugues Chabot added a comment - 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 ?

          Karol Tyl added a comment -

          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.

          Karol Tyl added a comment - 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.

          Hugues Chabot added a comment -

          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".

          Hugues Chabot added a comment - 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".

          Hugues Chabot added a comment -

          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?

          Hugues Chabot added a comment - 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?

          Karol Tyl added a comment -

          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.

          Karol Tyl added a comment - 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.

          slav dok added a comment -

          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.

          slav dok added a comment - 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.

            hugueschabot Hugues Chabot
            ktyl Karol Tyl
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: