Difference between revisions of "Converting the SVN Repository To Git"
(→Narrowing to the right sub-repo) |
(→Narrowing to the right sub-repo) |
||
| Line 20: | Line 20: | ||
^88bdebdbe0075cf43a36085219a6a2802068dbda | ^88bdebdbe0075cf43a36085219a6a2802068dbda | ||
| − | Where | + | Where there are now two references for a tag (7862 and 88bd). So, to fix this I manually edited the file to leave only one line with the newer reference being listed for the tag. This allowed git clone from the sourceforge server to properly pull the tags. |
But... The tags didn't get properly rewritten, it seems, and if you checkout out a tag you'll find that the code is still in the 'net-snmp' sub-directory and not in the current directory like it should be. | But... The tags didn't get properly rewritten, it seems, and if you checkout out a tag you'll find that the code is still in the 'net-snmp' sub-directory and not in the current directory like it should be. | ||
Latest revision as of 14:46, 28 June 2011
This page documents what was done to convert the Net-SNMP source code repository from SVN to Git on June 27th, 2011. It is here for historical purposes, and may help other projects that wish to do the same conversion.
Contents
svn2git
Of the various conversion choices (including 'git svn clone'), svn2git seemed like it would work the best. So this was run:
# svn2git --authors /home/hardaker/src/snmp/git-authors -m -v file:///home/hardaker/lib/sf-bkups/net-snmp-convert-svnrepo/
(this process takes a long time but is much faster with a local repository which is a copy of the data pulled from SourceForge. It only took about 4 hours to convert compared to many more that it would have taken to run it against an online repo)
Narrowing to the right sub-repo
With SVN the various "projects" (httpd, net-snmp, ...) existed at the top level. This isn't correct for the now separated repositories that git allows for. Thus, git's filter-branch was used to narrow the results:
# git filter-branch --subdirectory-filter net-snmp -- --all
Afterward, the packed-refs file wasn't really liked by the sourceforge git version (at least I think this is where the issue lies). It had lines in it like:
7862717b0cdb17f6c90b56ec41ee4a0f5006a301 refs/tags/Ext-5-6-1-1 ^88bdebdbe0075cf43a36085219a6a2802068dbda
Where there are now two references for a tag (7862 and 88bd). So, to fix this I manually edited the file to leave only one line with the newer reference being listed for the tag. This allowed git clone from the sourceforge server to properly pull the tags.
But... The tags didn't get properly rewritten, it seems, and if you checkout out a tag you'll find that the code is still in the 'net-snmp' sub-directory and not in the current directory like it should be.
Branch Merging Setups
In order to make it possible to follow the project's Git Branch Management strategies, the branches had to be set up to follow this paradigm. To do this, the following steps were performed. This step ensure that future merges from lower branches would only contain the newer code choices and that from a "future merges" perspective everything previous to this point would have been considered as "already merged".
# git checkout V5-1-patches # git merge -s ours V5-0-patches # git checkout V5-2-patches # git merge -s ours V5-1-patches # git checkout V5-3-patches # git merge -s ours V5-2-patches # git checkout V5-4-patches # git merge -s ours V5-3-patches # git checkout V5-5-patches # git merge -s ours V5-4-patches # git checkout V5-6-patches # git merge -s ours V5-5-patches # git checkout master # git merge -s ours V5-6-patches
Small Cleanups
- git config receive.denyNonFastforwards true
- git config core.sharedrepository 1
- delete the svn-remote and svn sections of the .git/config
- git gc --aggressive
Converting to a bare repo
# mv .git ../new-repo.git # cd ../new-repo.git # git config --bool core.bare true
Adding Hooks
- place the hook from here into hooks/post-receive
# git config hooks.mailinglist net-snmp-cvs@lists.sourceforge.net
