Child pages
  • Migration from Subversion (SVN) to Git

Access to add and change pages is restricted. See:

Skip to end of metadata
Go to start of metadata

Code Repository

The official repositories are on ASF Gitbox, only those are committers writable.

We have also Github mirrors. Committers can push to them they are synced to Gitbox, even using Subversion!
There are actually two mirrors, before and after release16.11.
Since release branch 16.11, we disentangled the plugin components (previously under the specialpurpose folder) into a separate repository called ofbiz-plugins

ASF Gitbox (official repository replacing Subversion now read-only, commiters writable)

Github (official mirrors of the ASF Gitbox repositories)

Synced with Gitbox, can be forked, and PRs can be made

release16.11 and previous releases

Trunk and releases after 16.11

Commiters: Github, Subversion and Gitbox

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
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: OFBIZ-11276 - Getting issue details... STATUS OFBIZ-11284 - Getting issue details... STATUS

I don't say it's a definitive solution. At least it allows to think more about the best solution...


  • 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 OFBIZ-11301 - Getting issue details... STATUS


As nicely explained by Taher A. Alkhateeb in the mail thread, here details on workflow.

The contribution workflow for small features/bug fixes 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 ->

Buildbot configuration with Git (Build Scripts)

  • We should make sure the buildbots are enabled on the commits for the above mentioned git repositories. I have created INFRA-19443 - Getting issue details... STATUS for that. Addressed in 

Revert workflow

The git revert command can use be revert a commit, more details can be found here.

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 and   See  OFBIZ-11297 - Getting issue details... STATUS

Release management

We will have a branch for the release management, currently we have three branches in

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 the trunk.

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.

git checkout -b release19.06
git push origin release19.06

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

Here is the example, we have cut a tag for release19.06 branch.
Make sure you are on release19.06 branch

git tag release19.06.01
git push origin release19.06.01

Equivalent of svn:auto-props properties

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.

Migrate svn pre/post commit hooks

As mentioned by Deepak Dixit, 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. INFRA-19376 - Getting issue details... STATUS

  • No labels


  1. If the 'large features approach' caters for pull-requests, why can't the similar approach be applied for the 'small features' approach? Both require vetting by other contributors, before it can be persisted to the main branch in the ASF repos by a contributor with the commit-bit.

  2. I think as a first step we have to focus on switching from svn to git. Once it has done we can discuss the contribution flow.

    1. I'd suggest to have the workflow in place and documented BEFORE we make the switch to avoid chaos and confusion.

      1. To keep it simple we can use the current workflow (Jira patch) . It will not affect the user/developer contribution.

      2. I think we should have a workflow in place with a gradual change. For instance, we can continue to have patches from the contributors but committers start using git. Initially we define workflow for the committers only and evolve it with broader participation by contributors (with PR etc). 

  3. >>Backport fixes

    I instead of committing script in each release branch we can move tools repo as well in github.

  4. Also we need to move ofbiz website code to git repo as well.

    1. Thanks Deepak,

      Yes that's it, the rest don't need to be moved. To be clear, we don't need to move:

      cmssite/ We don't use it, we have our onw site

      old-site/ I think we can get rid of it now

      Also we need to clean out the branches before moving them.

      Not sure about the tags, this should hopefully help (did not check)

      1. I think we don't need to worry about tags they are in old/archieve github repo

      2. Oops it seems I (Jacques Le Roux) used Modified instead of Answer (in French actually), sorry Deepak (smile)

        Deepak suggested to name ofbiz-tools and ofbiz-site for the sake of consistency, I rather suggested:

        Or tools and site, it's OFBiz after all, no need to add a prefix. Like we have not for other branches.

  5. I think we need to use ofbiz as prefix in git repo name, as we don't have separate group for ofbiz

    here is the example

    1. Ah, indeed missed that, thanks Deepak.

      BTW we are lucky that Github is only a mirror of ASF Gitbox:

    2. +1 Deepak to use ofbiz as prefix in git repo name.

  6. Thanks Swapnil Mane  for the efforts in this direction.

    For Revert workflow

    These links might help:

    For 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 and  

    We can directly use the existing cherry-pick command for new branches (after 17.12)

  7. Thank you Unknown User (adityasharma)  for reference link to revert, added the the respective information in document.

    For backporting the fixes, we can keep both the options.

    1. We will have script (similar to we have in SVN) to merge and commit the fixes from trunk to release branches.
    2. If a respective committer want they can use cherry-pick command.