This is an old revision of the document!
Since November 2014, the plugins repository and the translation platform both support Github repositories, in addition to our Subversion repository. That mean you can use the power of Github (issues, forks, pull-requests) and seamlessly integrate with piwigo.org (no more need of manual releases and/or git/svn mirrors).
This tutorial will guide you in the process to migrate your SVN repository to Github without loosing its history. It is inspired by Atlassian tutorial for migrating to Bitbucket but cleaned and adapted for Github. It is adapted for plugins with only one branch (trunk), if you have branches and/or tags on your plugin and wish to migrate them, please refer to the original tutorial.
I assume you will start with a fresh OS but you certainly have some or all of the required software. (The process was tested on Windows 7 and Ubuntu 14).
You can get Java JRE on Oracle website.
Subversion binaries can be found on Apache website.
Also install mysysGit containing both core Git and Git SVN.
You will need these packages :
openjdk-7-jre
(or openjdk-8-jre
)subversion
git
git-svn
In order to get a consistent commit history on Github you will have to tell Git SVN who is who. Open a terminal where svn-migration-scripts.jar
is located (Shift+Click on Windows) and enter the following command:
java -jar svn-migration-scripts.jar authors http://piwigo.org/svn/extensions/YOURPLUGIN > authors_YOURPLUGIN.txt
This will create a TXT file with the following syntax:
j.doe = j.doe <j.doe@mycompany.com> m.smith = m.smith <m.smith@mycompany.com>
Left part is Subversion login, right part is Github login and email.
Now modify the left part of each line to match an actual Github accounts. The email must be one of the emails associated to the Github account.
You will certainly get TranslationTeam
in this file, the SVN user used to commit language files. Complete the line as following:
TranslationTeam = Piwigo-TranslationTeam <translate-github@piwigo.org>
Also if plg
or mistic100
made changes in your plugin, use theses:
plg = plegall <plg@piwigo.org> mistic100 = mistic100 <mistic@piwigo.org>
For any other users, replace mycompany.com
by piwigo.org
.
And of course don't forget to specify the correct mapping for your own account!
Open your terminal on your working directory and type:
git svn clone --authors-file=authors_YOURPLUGIN.txt http://piwigo.org/svn/extensions/YOURPLUGIN
This will fetch all commits on your plugin and create locally all relevant Git commits.
Now it's time to push your plugin to Github.
Create a new repository. You must leave it empty (no README.md, no LICENSE, no .gitignore).
Still in your terminal type:
git remote add origin https://github.com/YOURLOGIN/YOURREPOSITORY git push -u origin --all
Hooray ! Your plugin is now published to Github.
Your plugin is already available in Extensions, time to update the plugin data to use your new Github repo instead of the SVN one.
Go to your page and select the migrated plugin, then click on the SCM icon .
Select Git and change the URL, don't change the other fields. You must give the root URL of your repo, for example https://github.com/Piwigo/ContactForm
, you will be able to choose a specific branch when publishing a new revision.
Validate. You should see the correct Git information in the bottom block, if not, double check the form.
If your plugin is available in Piwigo Translate some stuff has to be done to continue the translation on Github.
As on SVN we use a single user to push translations to all plugins, this user is Piwigo-TranslationTeam. You must give push access to the user on your repo.
To do so, on your repository page, go to Settings / Collaborators and add Piwigo-TranslationTeam.
We need to reconfigure Lexiglot to use your new repository. Contact one of the team members on the forum or send an email to translate-github [at] piwigo [dot] org to tell us what is the new location of your plugin.
By default all commits are pushed to the master branch, you can tell us if you want translations to be pushed to any other branch (the branch must already exists).
We decided to not use pull-requests because it's a bit more complicated to implement and we don't want to spam you with a bunch of PR every week (the translation team is very active !).