Skip to content

Instantly share code, notes, and snippets.

@tgirke
Last active April 15, 2020 00:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tgirke/233b263db6636ff520b4362a9d9fa144 to your computer and use it in GitHub Desktop.
Save tgirke/233b263db6636ff520b4362a9d9fa144 to your computer and use it in GitHub Desktop.
How to maintain Bioconductor package on GitHub and keep it in sync with SVN repository on Bioconductor

Maintain Bioconductor Package on GitHub


Table of Content

  1. Overview
  2. Script to create/update Bioc branches
  3. Create GitHub repository of your package
  4. Commit changes to GitHub and Bioc SVN
  5. Update repository after a new Bioconductor release

1. Overview

This page contains my personal notes for maintaining Bioconductor packages on GitHub and keeping them in sync with Bioconductor's SVN system using git svn. Additional information can be fund on these sites:

2. Script to create/update Bioc branches

Bioconductor provides a bash script called update_remotes.sh. This script automates the creation, tracking and updates of the different development and release branches from svn and the associated git mirrors. The script can be downloaded from here or with curl like this:

curl -O https://raw.githubusercontent.com/Bioconductor/mirror/master/update_remotes.sh

Note, the script can be located anywhere on a user's system.

3. Create GitHub repository of your package

Visit the static read-only mirror GitHub repository of your package. For a package named REPO it would be this URL: https://github.com/Bioconductor-mirror/REPO. Then fork it by clicking the Fork button. This will create a copy of the repository in your GitHub account. If needed turn on issue tracking for the new GitHub repository under settings. Note, everything up to here needs to be done only once for each package. Subsequently, clone the repository to your local machine and run the update_remote.sh script to set up the git remotes:

git clone https://github.com/USER/REPO 
cd REPO 
bash /path/to/update_remotes.sh

4. Commit changes to GitHub and Bioc SVN

The following workflow uses cherry-pick to sync changes made in the master branch to the devel branch. While less convenient, this method is more robust than the git merge approach recommended on the Bioc Git Mirror page. For more details, see here.

4.1 Updates to devel branch

Changes to the development version should be made in the master branch of a package's GitHub repository. Those changes are then synced with the devel branch using git cherry-pick.

git branch # Lists all branches. The * marks the branch that is checked out.
git checkout master # Switch to master branch. This is where you make changes to the development version of the package.
git pull --rebase # Update local git repository. Rebase is important here since it avoids a merge which is part of a normal git pull
## <<< DO WORK HERE AND COMMIT/PUSH TO GITHUB AS USUAL >>>
git commit -am "some edits"; git push -u origin master
git checkout devel # Switch to devel which is the one from where you commit to SVN
git svn rebase # Gets latest changes from Bioc SVN
git commit -am "update" # Commits those changes
## git merge master # To minimize problems, avoid this merge step. Instead use cherry-pick method as shown in next two lines
git log master # Figure out what commit IDs to use and cherry pick them. Note, only the 7 first digits of listed numbers are needed and a range of commits can be given with 'ID1..ID2'
# git log --oneline --decorate --graph --all # Print history of your commit with branch pointers
git cherry-pick 4df7159 # Syncs commit from master to devel, here for commit ID 4df7159. This syntax spcifies range of commits: 4df7159..3gb7153 
git svn dcommit # Now you should see changes on git mirror page
git commit -am "some edits"; git push -u origin devel
git checkout master # To be safe, switch back to master branch

4.2 Updates to release branch

Changes to the release version should be made in a separate working branch of a package's GitHub repository, just like under the developer branch. In the following this branch is created by making a copy of the current release-x-x branch and nameing it release-master. This name can be changed to anything. Changes to release-master are then synced to the current release-x.x branch using git cherry-pick (or git merge). The following assumes that the current release branch is release-3.3.

# The following line creates a copy of release-3.3 and names this copy release-master. This needs to be done only once!
# git checkout release-3.3; git branch release-master release-3.3; git checkout release-master; git push -u origin release-master 
git checkout release-master # Switch to release-master branch. This is where you make changes to the release version of the package
git pull --rebase # Update local git repository. Rebase is important here since it avoids a merge which is part of a normal git pull
## <<< DO WORK HERE AND COMMIT/PUSH TO GITHUB AS USUAL >>>
git commit -am "some edits"; git push -u origin release-master
git checkout release-3.4 # Switch to current release which is the one from where you commit to SVN
git svn rebase # Gets latest changes from Bioc SVN
git commit -am "update" # Commits those changes
## git merge release-master # To minimize problems, avoid this merge step. Instead use cherry-pick method as shown in next two lines
git log release-master # Figure out what commit IDs to use and cherry pick them. Note, only the 7 first digits of listed numbers are needed and a range of commits can be given with 'ID1..ID2'
# git log --oneline --decorate --graph --all # Print history of your commit with branch pointers
git cherry-pick 4df7159 # Syncs commit from release-master to release-x.x, here for commit ID 4df7159. This syntax spcifies range of commits: 4df7159..3gb7153 
git svn dcommit # Now you should see changes on git mirror page
git commit -am "some edits"; git push -u origin release-3.4
git checkout release-master # To be safe, switch back to release-master branch

5. Update repository after a new Bioconductor release

Twice a year a new Bioconductor release becomes available. Those newly created release branches need to be added to your local and remote GitHub repositories. To add a new release branch, the easiest is to re-clone the repository from GitHub and then re-run update_remotes.sh as outlined above under Create GitHub repository of your package. After this the old local copy of the repository can be deleted without loss of information assuming all its content has been synced to the remote version on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment