The aim is to have a local copy of an internal svn which is afterwards pushed automatically to Github.
The hard way, importing all history
1. Setup the svn:
2. Init the git-svn bridge:
3. The following step hurts: we need to rebase the trunk:
For each error, skip
(This is much easier than to handle all merge errors).
4. Show the merge errors and remove all merged data:
Be careful not to execute the command in the git-root since multiple HEAD-files are stored under .git.
5. Adapt this step for other merge error files not under version control and fix the files.
To be honest, fixing the merge errors resulting from the rebase is not really fun but necessary: Since all versions are replied and SVN is not able to handle branches in a way git/mercurial does, the rebasing is necessary. Scaling with the number of branches and tags, the rebasing need much interaction and time making the conversion of complete gits to svn questionable with respect to all use cases.
The easy way, importing only the last version
Relying only on the last version, I propose therefore a much more straight-forward approach, namely relying on only the last version.
1. Create a svn repo:
2. Checkout the repo and copy the actual version of the git-repo to this location:
3. Binding the svn as remote to the existing git:
4. Switching and building and merging on git site:
Note that this workflow relies on the following constraints:
- The svn relies not on the history of the git.
- The svn is always the one against which is actively developed. Gits commits must be merged manually.