-
New Feature
-
Resolution: Unresolved
-
Minor
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
- is blocking
-
JENKINS-15830 Error: Unable to infer the new branch name from XXX
-
- Open
-
- is related to
-
-
- Open
-
[JENKINS-22284] new field in the "feature branch" creation form, to manage multi-project repository layout
Verny Quartara Gutierrez
created issue -
Verny Quartara Gutierrez
made changes -
| Attachment | New: adv_options.png [ 25656 ] |
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. Hugues Chabot
made changes -
| Link | New: This issue is blocking JENKINS-15830 [ JENKINS-15830 ] |
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?
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. 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
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. Verny Quartara Gutierrez
made changes -
| Affects Version/s | New: current [ 10162 ] | |
| Due Date | Original: 2014-05-03 | New: 2014-05-11 |
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.