SVN to GIT migration with branch history merging
/ |-projectA |-projectB |-projectC |....
I want to migrate only projectA with keeping all it’s history. Sounds easy : ) But main problem is in structure and revision history inside projectA.
- what are some tools for documenting code changes?
- Error rebaseing/updating a git-svn repository
- Use Xcode 4 subversion integration with custom port?
- SVN server for Mac OSX
- Command line to update SVN folders
- Check subversion writable access for user
/ |-projectA | |-trunk | |-branches | | |-version 1.0 | | |-version 1.1 | | |-version 1.2 | |-tags
- 2009: we had only “trunk”, and all changes where committed to trunk
- 2010: branch version 1.0 was created based on trunk. Commits to
trunk and commits to version 1.0 (some customers had version from
trunk, some from branch)
- 2011: branch version 1.1 was created based
on version 1.0. Commits to trunk, commits to version 1.0 and 1.1
- 2012: branch version 1.2 was created based on version 1.1. Commits
to trunk, commits to version 1.0,1.1 and 1.2
Now we are going to upgrade all customers to version 1.2 and to migrate project to git.
what I want to migrate to GIT:
- new trunk of project with history:
- commits to trunk for 2009
- commits to version 1.0 for 2010 (represent as commits to trunk)
- commits to version 1.1 for 2011 (represent as commits to trunk)
- commits to version 1.2 for 2012 (represent as commits to trunk)
What I do not want to migrate:
- trunk history for period 2010-2012
- version 1.0 history for period 2011-2012
- version 1.1 history for period 2012
One Solution collect form web for “SVN to GIT migration with branch history merging”
Don’t be tempted to get all of the commits migrated over. It’s not worth the effort. Take the snapshots of each of the important tags, branches, etc. and commit them in git in a fashion that mirrors what was done in SVN.
Instead, keep the SVN history on a server, CD, DVD, etc so you can inspect things when you need to. You have just saved your sanity.