DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
The OFBiz community decides to migrate the code repository from Subversion (SVN) to Git, here is the communication thread.
This document contain all the details to migrate the code repository from SVN to Git and the workflow/processes to be adopted by community.
| Table of Contents |
|---|
Code Repository
The official repositories are on ASF Gitbox, only those are committers writable.
We already have read-only Git mirrors for the OFBiz Subversion repository. There are have also Github mirrors. Committers can push to them they are synced to Gitbox, even using Subversion!
There are actually two mirrors, before release16.11 and another is after the release16.11.
Since release branch 16.11, we disentangled the plugin components (previously under the specialpurpose folder) into a separate repository called OFBIZ-PLUGINSofbiz-plugins
ASF Gitbox (official repository replacing Subversion now read-only, commiters writable)
https://gitbox.apache.org/repos/asf/ofbiz-framework.git https://gitbox.apache.org/repos/asf/ofbiz-plugins.git https://gitbox.apache.org/repos/asf/ofbiz-site.git https://gitbox.apache.org/repos/asf/ofbiz-tools.git
Github (official mirrors of the ASF Gitbox repositories)
Synced with Gitbox, can be forked, and PRs can be made
release16.11 and previous releases
https://github.com/apache/ofbiz/
Trunk and releases after 16.11
Framework - https://github.com/apache/ofbiz-framework
https://github.com/apache/ofbiz-framework/Plugins - plugins
https://github.com/apache/ofbiz-site
https://github.com/apache/ofbiz-tools
| Info | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
| Note that you can use Subversion through those repository to finally commit to Gitbox. You can also checkout. A Github feature[1] allows that. You can do it by checking out from Github. For instance, simply try svn co https://github.com/apache/ofbiz-plugins/trunk/ecommerce If you then Svn commit, the Github repo will be the ending container and will sync to ASF Gitbox I have used the same in build.Gradle:
I don't say it's a definitive solution. At least it allows to think more about the best solution... [1] https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github |
- Communicate with ASF Infra team to enable write access in the above repositories.
- After successful migration to Git, mark the SVN repository as read-only
- PR can be asked but we have still to discuss if we want that to be used. I believe the Jira way should be still the official way. Clarification in progress, see
Jira server ASF JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-11301
Workflow
As nicely explained by Taher Alkhateeb by Unknown User (taher) in the mail thread, here details on workflow.
The contribution workflow for small features/bug fixes and and large features.
Small Features / Bug Fixes
Small features follow the exact same workflow that currently exists in SVN.
You do your work, diff it, and attach the patch to a JIRA and request a commit from one of the committers. As explained in Contributing via Git and Github - WIP
Large Features
For large features usually multiple people need to collaborate on a separate branch. Here is where git shines and the distributed model kicks in:
1. A JIRA is created for a large feature.
2. The team (not necessarily having a committer) creates a remote repository which itself may have many branches with the master branch having all the work agreed upon and merged (actually, rebased)
3. The collaboration for this branch happens in the JIRA including discussions, comments, and even links to the commits, etc ...
4. A request is made to the project, to make a pull request from the repository after reaching a certain milestone with consensus from the community of course.
5. Here, for extra safety, the branch model may have a trunk and a develop branches. Everything is pulled to the develop branch and trickles down to the master branch after thorough and proper testing.
The above workflow can also adhere to the now famous Vincent Driessen git branching model found here -> http://nvie.com/posts/a-successful-git-branching-model/
[Swapnil M Mane] - Recently (29 April 2019) the Apache® Software Foundation Expands Infrastructure with GitHub Integration. This will allow projects to use GitHub's excellent tools.
https://blogs.apache.org/foundation/entry/the-apache-software-foundation-expands
[Swapnil M Mane] - I think, we can also allow our contributors to create pull request (PR) for Small Features / Bug Fixes and this MR can be mentioned in the JIRA ticket.
In GitHub, contributors can easily fork the project, do the respective changes in their repository and submit pull request (PR) to merge their code change.
Buildbot configuration with Git (Build Scripts)
- We should make sure the buildbots are enables enabled on the commits for the above mentioned repositorygit repositories. I have created
Revert workflow
We need to explore more around this, below are some initial findings.
Revert Pull Request
If the code is merged via pull request. It can be directly revert from GitHub UI.
https://help.github.com/en/articles/reverting-a-pull-request
Revert a commit
for that. Addressed inJira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key INFRA-19443
Revert workflow
The git revert command can use be revert a commit, more details can be found here.
| Code Block |
|---|
git revert <commit-revision> |
...
Backport the fixes
In SVN we have script to merge and commit the fixes from trunk to release branches.
- All the releases are branches in the repository of Git, we can write similar script mergefromtrunk.sh(bat) and mergefromplugins.sh(bat) See
Jira server ASF JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-11297
Release management
We will have a branch for the release management, currently we have three branches in https://github.com/apache/ofbiz-framework/
trunk, release17.12 and release18.12
Cut a release
In OFBiz, we cut a release and thoroughly test it and then finally make it available to the public.
To create a new release, a branch will be cut from trunk. A branch can be cut manually using command line or through the UI of GitHub. Both process are mentioned below.
Manually cut a release branch using command line
the trunk.
Ideally, Ideally the branch will be cut from the trunk branch. So make sure you are on the trunk branch.
Here is the example, we have cut the release19.06.
| Code Block | ||
|---|---|---|
| ||
git checkout -b release19.06 git push origin release19.06 |
...
Please follow the link below
https://help.github.com/en/articles/creating-and-deleting-branches-within-your-repository
Publish the release
Once the branch is ready to publish, we will cut a tag to the release branch. As per our example above we can cut a tag release19.06.01
A tag can be cut manually using command line or through the UI of GitHub. Both process are mentioned below.
...
Here is the example, we have cut a tag for release19.06 branch.
Make sure you are on release19.06 branch
...
| Code Block | ||
|---|---|---|
| ||
git tag release19.06.01 git push origin release19.06 |
Reference - https://stackoverflow.com/questions/18216991/create-a-tag-in-a-github-repository
Cut the tag branch using GitHub UI
Please follow this link - https://stackoverflow.com/questions/18216991/create-a-tag-in-a-github-repository
The complete release management with GitHub is show here at link https://help.github.com/en/articles/creating-releases
Add detached signature and checksum file with release
I think, we can do this by uploading the binary files. Please reference Point-7 of this link https://help.github.com/en/articles/creating-releases.
TODO: We need to explore more on this.
.01 |
Equivalent of svn:auto-props properties
- As mentioned
...
- by Unknown User (jleroux), we should have an equivalent of svn:auto-props properties on the server.
Something we will need to not forget when we will switch to Git: https://help.github.com/articles/dealing-with-line-endings/#per-repository-settings
Update the website, wiki documents, and references
After the successful migration to Git, we should update this information to various resources like website, wiki documents, and references.
- Update the information related to Git on OFBiz website Unknown User (swapnilmmane) . See
Jira server ASF JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-11269
https://ofbiz.apache.org/source-repositories.html - Update the information related to Git to OFBiz tutorials Unknown User (swapnilmmane)
OFBiz Tutorial - A Beginners Development Guide - Update https://projects.apache.org/project.html?ofbiz We now need to move from svnpubsub to gitpubsub
Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-11268
Migrate svn pre/post commit hooks
As mentioned by Unknown User (deepak), we have hooks on commits, like the word limit in a line for Java file.
- Check and migrate the svn pre/post commit hook for Git.
Update the RAT tool if needed to use git repository
- Check if we are using any RAT related thing, and impact of using Git repository on this. We finally use the associated Svn repo associated by Githhub, it works.
Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key INFRA-19376