-
Notifications
You must be signed in to change notification settings - Fork 149
SvnToGit
Jonathan Guyer edited this page Sep 26, 2014
·
1 revision
As we've discussed for awhile, we want to migrate the source repository from SVN to git.
As discussed in step 1 of http://john.albin.net/git/convert-subversion-to-git, a decent first cut at a list of users we'll need to provide can be made by going to an SVN checkout of FiPy and running
After filling in full names and email addresses:
note: including `--branches=vendor` and `--branches=sandbox` causes all kinds of conflict warnings and probably isn't what we want, anyway. We can `fetch` those later or, better yet, just either leave them where they are or extract them as independent git repositories.
The following script should be run for each "`patt`", commenting and uncommenting the "`merged log:`", "`merged source:`", etc. strings, respectively. [#ManualEdits] need to be done after each run. It may be necessary to [#Hackgit-svn].
I had to apply the following patch to `git-core/git-svn`
otherwise I get tons of
Wheeler doesn't see this?
After each run of the [#FixMerges], a number of lines in `.git/info/grafts` will need to be edited by hand.
* Move `.git/info/grafts` aside (I moved each run of [#FixMerges] into a separate file and then merged them by hand later),
or you will get a bunch of messages like
* Open `.git/info/grafts` in an editor and scan for lines like
These lines failed to convert because the revision number listed is not exactly the revision number of the commit and `git-svn` isn't smart enough to figure it out. * First, pull up the commit message for the first SHA on the line
The second SHA on the line should be listed as the `parent:`. * Sometimes you'll get two parents back from `git cat-file`:
These merges were already identified by `git-svn` from the merge info stored by newer versions of SVN. These lines can be safely deleted from `.git/info/grafts`. * The branch and revision number from the comment will usually not retrieve anything:
* Using the tool of your choice, find the last valid commit on the appropriate branch before the given revision number (I find Trac easiest).
* Enter this SHA in place of the third, faulty entry on the line.
* Lather, rinse, repeat
* The "`merge source:`" variant of the script illuminates a weird structure in the commit history that arises because of James' r3610 (cbca4c62cc8f0890a7829b75c1021d66605fe878), which he realized was a mistake in r3611, but deletions don't get migrated to git. It's best to clean up this crazy history before we proceed.
* We'll add a graft to jumper what we want. The subsequent commit that we want is ce6c50184e2353314ac723cc1e0177dac92b0cf9 and its other parent is 0c024624fa1f043a57f41ae6a0a48ebc0c7bf0b6. The desired parent of cbca4c62cc8f0890a7829b75c1021d66605fe878 is f7e0b1fcda502075d209611a397f27d0d39917b6:
* The weird history remains unless we remove `partitioning@3609` from `.git/packed-refs` (or maybe `.git/refs/remotes`?)
* A manual comparison with
reveals 33 entries that no longer occur as a result of fixing the `partitioning` branch in the step above. We remove all of these from `.git/info/grafts`.
This will have to be tracked down manually * Comparison with
reveals eleven more. * `ticket:291` is either not found or confused for a range?
* `ticket:101` ditto
* `ticket:145` ditto
* already accounted for ???
* already accounted for ???
* already accounted for ???
* already accounted for ???
* poorly formatted
* poorly formatted
* Put `.git/info/grafts` back
* Make the tag branches into proper tags
* A bunch of tags got moved by `git gc` into `.git/packed-refs`, such as
Make manual entries in `.git/refs/tags/` with the tags we actually want and delete all of them from `.git/packed-refs` * Because of the difference between the way SVN and git work, the tags are all on commits that branch off of the actual commit. In git, we'd just like to tag the proper commit. We do this manually by replacing the content of the tag with the parent of that commit. * '''note:''' Tags `version-1_1`, `version-1_2_2`, and `version-2_0_2` are a little weird as all got re-tagged a couple of times and so git shows their merge history including all of the previous tags. Do we want that? At least `version-1_1` would require grafts to fix. * Make local branches of the extant SVN branches
with
* Scan for all un-merged heads and figure them out manually
||Newton-Raphson||deleted|| ||SourceForge||deleted|| ||abstractBaseClass||FIXED|| ||animate_CEAC||FIXED|| ||anisotropy||FIXEDish|| ||benchmark-old||renamed `benchmark-older-fipy`|| ||branch-additiveTerms||FIXED|| ||branch-distanceVariableRefactor1||FIXED|| ||branch-numerix||deleted|| ||branch-numpy||FIXED|| ||branch-periodicBoundaryConditions||FIXED|| ||branch-periodicMesh||FIXED|| ||branch-spectral||deleted|| ||branch-test||deleted|| ||branch-variable-inline||FIXED|| ||branch-variable_arithmetic||FIXED|| ||branch-variable_caching||FIXEDish|| ||branch-version-0_1||feeds to `version-0_1`|| ||branch-version-1_0||feeds to `version-1_1`|| ||branch-version-1_1||feeds to `version-1_1`|| ||branch-windows-dist||deleted|| ||commonSpotting||deleted|| ||commonSpotting@3016||feeds to `commonSpotting`|| ||electrical||deleted|| ||epydoc-2_1||deleted|| ||epydoc-hack||deleted|| ||epydoc-hack@2752||feeds to `epydoc-hack`|| ||examplesFromFred2||deleted|| ||faceMasks||FIXED|| ||getset||deleted|| ||inline||FIXED|| ||levelSetRefactor||deleted|| ||lewisd2_FiPy_Workbook||deleted|| ||maxTest1||FIXED|| ||numpy||deleted|| ||obuzek||feeds to `parallel`|| ||pysparse_precon||FIXED|| ||rankVariables||FIXED|| ||reimann||deleted|| ||scipySolvers||deleted|| ||spectral||deleted|| ||sphinx||deleted|| ||steppers||deleted|| ||termEquations||FIXED|| ||termMultiplication||deleted|| ||termProperties||FIXED|| ||test-test||deleted|| ||ticket%3A296||deleted|| ||ticket%3A441||deleted|| ||ticket145||deleted|| ||trilinos||FIXEDish|| ||trilinos@2764||feeds to `parallel`|| ||variable-inline||deleted|| ||windows-dist||deleted||