3

I'm trying to do a permanent migration of my codebase from svn to git, and hit a wall due to externals.

I make liberal use of svn externals. I couldn't have anticipated one day wanting to migrate to something that is less flexible, as git submodules are. I have hundreds of svn externals accumulated over the years, not just pointing to a subdirectory in an external related repo (also my own code), but sometimes to a subdirectory in a different branch/path of the same repo, sometimes by relative path and sometimes by absolute path. Sometimes the pointed target is at a specific revision, sometimes the tip.

I've given up on migrating the svn externals, you can't fit a square peg into a round hole. It only works if you're using svn externals in a very simple way that was already in line with git submodules' limitations. To migrate and keep a valid history, I don't see any solution other than removing all externals and replacing them with local changes. I'll have code duplication, but that's an acceptable for valid history, as I have to support more than just the latest snapshot of the codebase.

Pseudocode of what I hope to achieve:

for each branch:
    for each revision in that branch, from first to last, migrate it to a git commit (as 'git svn clone' does)
        if the revision has any svn externals, copy the directory/file content as is and commit it as if it were local changes, using the same commit message, ('git svn clone' can't do this)
        if the contents of the externals were modified in a later revision, then modify the local files in a git commit too

Final result: a standard git repo with my desired branches and their full history. If git commit 
abcdef123 == svn rev 123, then I get the same file tree from 
"git clone git.example.com/gitrepo && git checkout abcdef123" as I do from 
"svn checkout svn://example.com/svnrepo --revision 123".
If 2 branches evolved from the same ancestor, then that should be reflected in git.

After the migration, I would start doing things the git-appropriate way: manually replace the local files with new git submodules pointing at the external repos, and update the project's filepaths accordingly.

How can I achieve this?

phd
  • 82,685
  • 13
  • 120
  • 165
  • 1
    https://stackoverflow.com/a/350982/7976758 Found in https://stackoverflow.com/questions/tagged/git+svn-externals – phd Oct 23 '20 at 22:34
  • That script doesn't help migrations. It just tries to clone externals, and seems quite brittle at that too compared to Smartgit. It's: a) a local-only solution (uses Linux symlinks), and b) temporary in nature, as it's only valid only for the currently checked out commit. – jerkstorecalled Oct 24 '20 at 17:25
  • There is no right solution for svn:externals. https://stackoverflow.com/a/12625342/7976758 – phd Oct 24 '20 at 17:30
  • That's for people who want to use git and svn simultaneously. This is not my scenario, which is a one-time permanent migration away from svn. The solution I suggested to find is a valid way to perform this one-time migration, by getting rid of externals altogether. – jerkstorecalled Oct 25 '20 at 19:02

0 Answers0