An internal repository with source code and testcases should act as a base for active development (SVN, HG, Git). A corresponding project on any open source portal with an decentralized repository (SVN, HG, Git) should be synced with tested sources.

In this article, the synchronization between Github and a local SVN is described. Other open source portals like Sourceforge should be able to be synchronized in a similar way.

Wants:

An automatic (more or less instant) synchronization between the active developed version on the internal repository and the remote repository on the open source portal.

Tools:

  • Testcases of any kind
  • Maven (e.g. generation of project-websites and jars)
  • A continuous integration server
  • An internal SVN-repository
  • A remote Git-repository

Workflow:

1. [If not a suitable job to the project exists within the CI:] Create a job. Log in the server and go the location of the workspace to establish the first connection. Within Jenkins, the path is jenkins/jobs/JOB/workspace.

2. First, we need to establish a Git-SVN connection similar to this article.

3. After setting up a Git repository on the CI, the workflow of synchronization works as follows:

3.1. Getting the data from the svn:

#getting github data
git fetch origin
#getting disy data
git svn fetch
git checkout refs/remotes/git-svn

The data is loaded in the remove branch: refs/remotes/git-svn.
Since we need the branch only for reading, we can directly switch to this remove branch.

3.2. Execute your maven goals (clean _deploy_in our case):

mvn clean deploy -U

The data is pushed to the maven-repo directly.

3.3. After successful execution, everything should be merged and pushed to the Git-repo:

#switching back to master
git checkout master
#merging the data
git merge refs/remotes/git-svn
#submitting to github
git push origin

Note that no merge errors should occur since Git-repos are user-bound normally. If you are working on your Git-data as well as on the SVN, you have to tackle merging errors. Otherwise, the workflow above handles publishing of internal repos to open source portal very efficiently since only tested source-code is published even though the different commits stay retrieval over the history: Only the last push must be handled by a specific user.