CODEWITHSUNDEEP
gitsvngitlabgit-svn
Prashant
Prashant

Reputation: 5383

Migrating huge SVN repository to GIT with minimum freeze time on the SVN repositories

I am working on a project that has been running from quite some time now. It is hosted on SVN. It has 24K revisions. Someone in the organisation thought (and I agree) it would be great if we could migrate all the projects in the organisation from SVN to GIT. Its easy said than done. Our project is a very critical to maintaining inventories and is due in production next quarter. The timeline for migration is set to December end. This means that we neither have a wait time nor the luxury of freezing the SVN repository. I decided to take following approach:

  1. Create a dump of the current repository using svnrdump. This took around 3Hrs.
  2. Load the dump to the local svn repository. This took around 12Hrs.
  3. Convert local svn repositories to git using git svn clone. This takes more than 73Hrs.
  4. Push this git repository to the remote.

Now while these steps were being performed, some new commits were made to the existing remote SVN repository. Is there a way, I could merge these new changes to the new remote git repository. It is worth noting that we want to retain all the commit histories from SVN. If there is a way to do this, it would mean that we will have to freeze the current remote SVN only for a couple of hours. I would also like to mention that our new git repository is hosted on gitlab. Is there a better way of doing this?

Upvotes: 1

Views: 744

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97292

JFYI: SubGit in "sync" mode will give you automatic mirroring of changes and zero downtime

Upvotes: 0

VonC
VonC

Reputation: 1325966

Considering the differences between svnrdump and svndump, check first if a locally done (directly on the server) svndump (if you do have access to said server) would not be faster.

Then, for the few commits/revisions created concurrently, you can do an svnrdump --incremental.

Dump a revision or revision range only as a diff against the previous revision, instead of the default, which is begin a dumped revision range with a complete expansion of all contents of the repository as of that revision.

You can convert that into its own Git repository, fetch it into your current Git repo, and rebase/cherry-pick the orphan branch on top of your normal Git branch, to keep the history. (See an example here)

Upvotes: 1

Related Questions