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

new field in the "feature branch" creation form, to manage multi-project repository layout

      When creating a new feature branch, the current version asks the user for the branch name and an optional commit message.
      In the case of a single-project repository layout, that works just fine: a new branch is created under "/branches" using the provided name, and the source code is copied directly into the new branch; besides, a new job is created with a name composed by concatenating the original job name with the name of the new branch.

      In case of a multi-project repository layout (http://svnbook.red-bean.com/en/1.0/ch05s04.html), the location of the new branch must be composed by concatenating the branch name and the sub-project name. This can be achieved using a simple workaround: specifing the complete location of the new branch in the "branch name" input field, e.g. "mynewbranch/projX". This approach is error prone and one drawback is the name of the new job which results in a long and possibly non-intuitive name that must be changed manually. (e.g. "projX-mynewbranch-projX")

      In addition, since we've adopted a development process that forbids direct development in trunk, we need to tag the trunk version when creating a new branch, to track back the state of the trunk in the moment the new branch is created. In particular, we have a tags/dev folder in our repo for that kind of tags, and a tags/rel folder for the effective released versions.

      To address the needs of this scenario, I suggest to implement more fields in the "new feature branch creation" page, to give the user the means to control the newly created job in a more fine-grained way, including the opportunity to create a tag while creating the branch.
      Let me know if this feature can be useful for the community, I'm going on with the analysis to provide a more concrete proposal.
      I'm available to take in charge the development.
      Cheers

      Verny

          [JENKINS-22284] new field in the "feature branch" creation form, to manage multi-project repository layout

          I did a little more analysis on the feature: I'm thinking about something like in the attached picture (adv_options.png).

          If "Single Project Repository Layout" is selected, everything works as is now.

          If "Multi Project Repository Layout" is selected, the user can optionally specify a "subproject name" (that is the actual subfolder under /branches/branchname).

          If "Create a development tag" is checked, a tag will be created and the user can optionally specify a "Tag subfolder" value (that is the actual subfolder under /tags).

          Some examples, given job name = "testproject" and Branch Name = 1.6.0
          a) with "Single Project Repository Layout" selected, a new branch will be created in /branches/1.6.0 and the new job name will be "testproject-1.6.0
          b) with "Multi Project Repository Layout" selected, a new branch will be created in /branches/1.6.0/testproject (unless the user specify another name using the "Subproject name" text input) and the new job name will be "testproject-1.6.0"
          c) with "Create a development tag" checked, a new tag will be created in /tags/dev/1.6.0 (unless the user specify another name using the "Tag subfolder" text input)

          I hope this proposal is not too tied to my current development environment, in that case you should provide others scenarios to merge with.

          Verny Quartara Gutierrez added a comment - I did a little more analysis on the feature: I'm thinking about something like in the attached picture (adv_options.png). If "Single Project Repository Layout" is selected, everything works as is now. If "Multi Project Repository Layout" is selected, the user can optionally specify a "subproject name" (that is the actual subfolder under /branches/branchname). If "Create a development tag" is checked, a tag will be created and the user can optionally specify a "Tag subfolder" value (that is the actual subfolder under /tags). Some examples, given job name = "testproject" and Branch Name = 1.6.0 a) with "Single Project Repository Layout" selected, a new branch will be created in /branches/1.6.0 and the new job name will be "testproject-1.6.0 b) with "Multi Project Repository Layout" selected, a new branch will be created in /branches/1.6.0/testproject (unless the user specify another name using the "Subproject name" text input) and the new job name will be "testproject-1.6.0" c) with "Create a development tag" checked, a new tag will be created in /tags/dev/1.6.0 (unless the user specify another name using the "Tag subfolder" text input) I hope this proposal is not too tied to my current development environment, in that case you should provide others scenarios to merge with.

          Hugues Chabot added a comment -

          The Multi Project Layout is documented in the Subversion Book. I think it should be well supported by the plugin.

          However, is it possible to handle that directory structure in a general way? For instance, given a SVN path prefix/(trunk|branches)(/suffix)? and a branch name feature, we could create the new branch in prefix/branches/feature/suffix. In the case of a multi projects layout, suffix is the sub-project name, isn't it?

          In the end, the advanced options could be the complete path of the branch/tag with default values based on your proposal.

          Hugues Chabot added a comment - The Multi Project Layout is documented in the Subversion Book . I think it should be well supported by the plugin. However, is it possible to handle that directory structure in a general way? For instance, given a SVN path prefix /(trunk|branches)(/ suffix )? and a branch name feature , we could create the new branch in prefix /branches/ feature / suffix . In the case of a multi projects layout, suffix is the sub-project name, isn't it? In the end, the advanced options could be the complete path of the branch/tag with default values based on your proposal.

          Yes, the directory structure should be handled in a general way, and yes the suffix in your example is the sub-project name.
          What should be the caption of the form input fields, in your opinion? As in your example?

          Verny Quartara Gutierrez added a comment - Yes, the directory structure should be handled in a general way, and yes the suffix in your example is the sub-project name. What should be the caption of the form input fields, in your opinion? As in your example?

          Hugues Chabot added a comment -

          Suppose one create a new feature branch named feature. Here are some examples of the default branch URL based on the upstream URL.

          Upstream SVN URL Branch SVN URL (default)
          http://svnserver/trunk http://svnserver/branches/feature
          http://svnserver/branches/other http://svnserver/branches/feature
          http://svnserver/trunk/subproject http://svnserver/branches/subproject/feature
          http://svnserver/branches/subproject/other http://svnserver/branches/subproject/feature
          http://svnserver/project/trunk http://svnserver/project/branches/feature
          http://svnserver/project/branches/other http://svnserver/project/branches/feature

          These examples differ from what is proposed in this issue's first comment. I am used to see the feature branch name at the end of the URL but it may be a matter of personal taste.

          Hugues Chabot added a comment - Suppose one create a new feature branch named feature . Here are some examples of the default branch URL based on the upstream URL. Upstream SVN URL Branch SVN URL (default) http://svnserver/trunk http://svnserver/branches/ feature http://svnserver/branches/other http://svnserver/branches/ feature http://svnserver/trunk/subproject http://svnserver/branches/subproject/ feature http://svnserver/branches/subproject/other http://svnserver/branches/subproject/ feature http://svnserver/project/trunk http://svnserver/project/branches/ feature http://svnserver/project/branches/other http://svnserver/project/branches/ feature These examples differ from what is proposed in this issue's first comment. I am used to see the feature branch name at the end of the URL but it may be a matter of personal taste.

          In the case of multi project layout, more than a matter of personal taste, it can depends on how much related the subprojects are: look at this question that refers to the CollabNet Subversion blog.

          I agree that it's common to have the feature branch name at the of the URL, so I suggest to support these kind of URLs in addition to that listed above:

          Upstream SVN URL Branch SVN URL(default)
          http://svnserver/project/trunk/subproject http://svnserver/project/branches/feature/subproject
          http://svnserver/project/branches/feature/subproject http://svnserver/project/branches/anotherfeature/subproject

          This lead to have the feature branch creation form a little bit more complex, but this way we'll be able to handle the three cases:

          • single project layout
          • multi project layout with non-related projects or loosely-related projects
          • multi project layout with closely related project

          Verny Quartara Gutierrez added a comment - In the case of multi project layout, more than a matter of personal taste, it can depends on how much related the subprojects are: look at this question that refers to the CollabNet Subversion blog. I agree that it's common to have the feature branch name at the of the URL, so I suggest to support these kind of URLs in addition to that listed above: Upstream SVN URL Branch SVN URL(default) http://svnserver/project/trunk/subproject http://svnserver/project/branches/ feature /subproject http://svnserver/project/branches/feature/subproject http://svnserver/project/branches/ anotherfeature /subproject This lead to have the feature branch creation form a little bit more complex, but this way we'll be able to handle the three cases: single project layout multi project layout with non-related projects or loosely-related projects multi project layout with closely related project

          Hugues Chabot added a comment -

          I understand, it makes a lot of sense to support the "multi project layout with closely related project" too.

          Hugues Chabot added a comment - I understand, it makes a lot of sense to support the "multi project layout with closely related project" too.

          latest proposal of the new branch creation form

          Verny Quartara Gutierrez added a comment - latest proposal of the new branch creation form

          Updated the screenshot of my proposal.

          The use of regular expressions simplifies the repository layout detection (based on the upstream svn url) and in most cases can detect automatically the new branch location, without the need to manually provide the subproject name (if any). When the repository layout does not follows standard conventions, as mentioned in JENKINS-15830, the user is needed to manually provide the new branch url.

          In conclusion, I changed my initial idea and now I believe that doing a little bit more advanced use of regex we can support a good range of repository layouts, substantially resolving the other mentioned issue as well.

          It's important to point that using regex these urls

          cannot be distinguished, so we have to assume a convention for the multi layout case.
          I assumed the branch name always follows the "branches" folder, so for example for the following upstream svn url

          the default new branch location will be: http://svnserver/branches/<new_branch_name>/other/

          Here is the complete list of the different upstream URL supported:

          Upstream SVN URL Branch SVN URL (default) Tag SVN URL (default, optional)
          http://svnserver/trunk http://svnserver/branches/<new_branch_name> http://svnserver/tags/dev/<new_branch_name>
          http://svnserver/branches/other http://svnserver/branches/<new_branch_name> http://svnserver/tags/dev/<new_branch_name>
          http://svnserver/trunk/subproject http://svnserver/branches/<new_branch_name>/subproject http://svnserver/tags/dev/<new_branch_name>/subproject
          http://svnserver/branches/other/subproject http://svnserver/branches/<new_branch_name>/subproject http://svnserver/tags/dev/<new_branch_name>/subproject
          http://svnserver/project/trunk http://svnserver/project/branches/<new_branch_name> http://svnserver/project/tags/dev/<new_branch_name>
          http://svnserver/project/branches/other http://svnserver/project/branches/<new_branch_name> http://svnserver/project/tags/dev/<new_branch_name>
          http://svnserver/project/branches/feature/subproject http://svnserver/project/branches/<new_branch_name>/subproject http://svnserver/project/tags/dev/<new_branch_name>/subproject
          http://svnserver/project/trunk/subproject http://svnserver/project/branches/<new_branch_name>/subproject http://svnserver/project/tags/dev/<new_branch_name>/subproject
          http://svnserver.com/FolderTrunk/Folder2/Folder3/Folder4/ProjectName unable to infer, user must provide the url unable to infer, user must provide the url
          http://svnserver.com/FolderBranches/Folder2/A/B/C/FeatureBranch unable to infer, user must provide the url unable to infer, user must provide the url

          Verny Quartara Gutierrez added a comment - Updated the screenshot of my proposal. The use of regular expressions simplifies the repository layout detection (based on the upstream svn url) and in most cases can detect automatically the new branch location, without the need to manually provide the subproject name (if any). When the repository layout does not follows standard conventions, as mentioned in JENKINS-15830 , the user is needed to manually provide the new branch url. In conclusion, I changed my initial idea and now I believe that doing a little bit more advanced use of regex we can support a good range of repository layouts, substantially resolving the other mentioned issue as well. It's important to point that using regex these urls http://svnserver/branches/subproject/branchname http://svnserver/branches/branchname/subproject cannot be distinguished, so we have to assume a convention for the multi layout case. I assumed the branch name always follows the "branches" folder, so for example for the following upstream svn url http://svnserver/branches/subproject/other the default new branch location will be: http://svnserver/branches/ <new_branch_name>/other/ Here is the complete list of the different upstream URL supported: Upstream SVN URL Branch SVN URL (default) Tag SVN URL (default, optional) http://svnserver/trunk http://svnserver/branches/<new_branch_name> http://svnserver/tags/dev/<new_branch_name> http://svnserver/branches/other http://svnserver/branches/<new_branch_name> http://svnserver/tags/dev/<new_branch_name> http://svnserver/trunk/subproject http://svnserver/branches/<new_branch_name>/subproject http://svnserver/tags/dev/<new_branch_name>/subproject http://svnserver/branches/other/subproject http://svnserver/branches/<new_branch_name>/subproject http://svnserver/tags/dev/<new_branch_name>/subproject http://svnserver/project/trunk http://svnserver/project/branches/<new_branch_name> http://svnserver/project/tags/dev/<new_branch_name> http://svnserver/project/branches/other http://svnserver/project/branches/<new_branch_name> http://svnserver/project/tags/dev/<new_branch_name> http://svnserver/project/branches/feature/subproject http://svnserver/project/branches/<new_branch_name>/subproject http://svnserver/project/tags/dev/<new_branch_name>/subproject http://svnserver/project/trunk/subproject http://svnserver/project/branches/<new_branch_name>/subproject http://svnserver/project/tags/dev/<new_branch_name>/subproject http://svnserver.com/FolderTrunk/Folder2/Folder3/Folder4/ProjectName unable to infer, user must provide the url unable to infer, user must provide the url http://svnserver.com/FolderBranches/Folder2/A/B/C/FeatureBranch unable to infer, user must provide the url unable to infer, user must provide the url

          Code changed in jenkins
          User: Hugues Chabot
          Path:
          .gitignore
          src/main/java/jenkins/plugins/svnmerge/IntegratableProjectAction.java
          src/main/java/jenkins/plugins/svnmerge/RepositoryLayoutEnum.java
          src/main/java/jenkins/plugins/svnmerge/RepositoryLayoutInfo.java
          src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/_attach.groovy
          src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/_attach.properties
          src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/index.groovy
          src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/index.properties
          src/test/java/jenkins/plugins/svnmerge/RepositoryLayoutInfoTest.java
          http://jenkins-ci.org/commit/svnmerge-plugin/6598e037fd58781bbc0c1965e322219cca2c535d
          Log:
          Merge pull request #13 from hugueschabot/jenkins-22284

          [FIXED JENKINS-22284] Improve branch creation
          [FIXED JENKINS-15830] Error: Unable to infer the new branch name from XXX

          Compare: https://github.com/jenkinsci/svnmerge-plugin/compare/ca285ed64c31...6598e037fd58

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Hugues Chabot Path: .gitignore src/main/java/jenkins/plugins/svnmerge/IntegratableProjectAction.java src/main/java/jenkins/plugins/svnmerge/RepositoryLayoutEnum.java src/main/java/jenkins/plugins/svnmerge/RepositoryLayoutInfo.java src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/_attach.groovy src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/_attach.properties src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/index.groovy src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/index.properties src/test/java/jenkins/plugins/svnmerge/RepositoryLayoutInfoTest.java http://jenkins-ci.org/commit/svnmerge-plugin/6598e037fd58781bbc0c1965e322219cca2c535d Log: Merge pull request #13 from hugueschabot/jenkins-22284 [FIXED JENKINS-22284] Improve branch creation [FIXED JENKINS-15830] Error: Unable to infer the new branch name from XXX Compare: https://github.com/jenkinsci/svnmerge-plugin/compare/ca285ed64c31...6598e037fd58

          Alex Ouzounis added a comment -

          related if not duplicate

          Alex Ouzounis added a comment - related if not duplicate

            kohsuke Kohsuke Kawaguchi
            verny Verny Quartara Gutierrez
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: