CODEWITHSUNDEEP
gitsvnversion-controlgit-svn
Daniel Gadawski
Daniel Gadawski

Reputation: 1923

Moving from git-svn to git

We keep our project's main repository at SVN. Then, to make work easier, each of us did git svn clone SVN's trunk to git's master and we work using git flow. When our work is done within feature branch, we merge it into master and do git svn dcommit to push changes to SVN repository.

But now we need to abandon SVN repository and switch completely to git. How can we achieve it if we want to keep history and branches which haven't merged into master yet?

I thought it that way: we make a clean copy of current SVN repository with git svn clone and place it on our server - it will be our "central" repository. Now, we'll add this repository as remote to our existing repositories. But how can I do it? Can I change old master with the new one? Can I then merge old, not yet merged feature branches to new master without unnecessary conflicts?

Upvotes: 0

Views: 175

Answers (2)

A.H.
A.H.

Reputation: 66283

Since you abandon SVN completely you can tell everyone to commit their open feature branches into SVN branches at a certain cut-over date. Then "freeze" SVN, convert it to Git (including the feature branches). After that each developer can clone the new repository and continue work easily.

Since SVN does not matter after the cut-over date the "dirty", half-ready feature branches don't matter any more.

Upvotes: 0

eftshift0
eftshift0

Reputation: 30297

Let's start from the beginning: You should set up a "clean" svn clone on git without any of the private work that the separate developers did. This is so that you can all share the same revisions, otherwise people will have divergent histories that won't be able to get together.... or even worse, multiple revisions on git that actually match a single svn revision.

Then, each one of the developers can use this repo as an official "remote" that they can add to their current set up. Once they have that, they could rebase their private branches at will so that no one loses any of their previous work (I'm not saying this is a trivial thing.... each branch will have a different starting point so if you want to do the work correctly, each branch has to be treated separately.... might even consider using a script that could take care of the analysis of finding matches between the old svn revisions and the new revisions from the new common svn clone) and then you (each developer) can get rid of the original (svn) remote repo that they were using in the beginning so that you can now start interacting with pure git workflows and forget about the svn interactions.

Upvotes: 2

Related Questions