Conversion svn -> git. Episode one


I don’t want to continue the thread, may be ignite the interest to the theme. 

I did the git svn clone from my workstation. 

The full conversion process was very very tough. The jira svn server has many times rejected the pear connection and I should  kick it from time to time. Second the current structure of svn repo is the broken. The removing a tag and adding same name latter cause the git-svn to aggressively search into the history the from the beginning.  Additionally old versions has multiply versions of huge *.swf files, which do not accelerate the common process too.  

Now I’ve finished  the pushing to the github, see liquibase-CORE repo. Please look at it thoroughly whether conversion is correct or not. It contains not full history, current references to branches and tags I pushed manually. If it make sense I add another branches/tags, by your request.

I’m hope we could migrate from svn to git. The main obstacle is the JIRA issues. I did google and found git plugin for JIRA. Nathan could you please ask  Attlasians’ people how to use one for our needs.

For this period of transition I can maintain the synchronization SVN => GIT, to keep the git repo fresh. It might be the github facility but I have never explored it.

If migration will be accepted I could start with CONTRIB sources.


A bit more background: Oleg contacted me about wanting to do a conversion to github. My initial response was the earlier (I’d like to wait until 2.0.2 is out) but he had some 2.1 related change he would like to work on. 

Looking at what is assigned to 2.0.2 in jira and my recent shortness in time to work on liquibase, I decided it is probably worth doing the github conversion now and see how it helps the 2.0.2 and 2.1 management, since it sounds like Oleg and some others are interested in doing some 2.1 work and I don’t want to stop anyone from helping out :slight_smile: Therefore, I changed my stance and want to do the github conversion now.

My end goals are:

  1. Having the official liquibase repository at github/liquibase

  2. Me understanding how the process conversion process works

  3. Any other git and/or github configuration needed to help make contribution flow work done

Ideally, I would have liked to do the svn->git conversion that you did, Oleg, but since you said it was ugly I don’t want to re-do it. Do you have some examples of the tag removing/adding that caused problems? I’m fine not having the .swf files in git if that helps.

I’d be fine holding off on the jira integration for now until we get github set up correctly.

Can someone who knows more about git than I do double check the repository Oleg created? Can that repository be moved to github/liquibase? Or is it better to import it into the the final project name originally?

I think we don’t need to worry about contrib. The idea behind contrib is to be a repository for people who don’t have a public repository of their own. If they want SVN, they can continue to use CONTRIB, if they want to use github, they can just use their own project. Contrib is just a convenience.

Anything else we need to worry about?


First questionable point is r573 where git-svn returns to the 247 version. Next stops are more painful r1543, after that looking started from the beginning. It went through all branches, tags and trunk. In r1548 it load the whole structure of the svn repository to one git commit. For guys are interested I could send the protocol (rared ~400 Kib).

After finishing  the plain vanilla ‘git svn clone’ and pushing it at the github I stumbled upon svn2git project ( This is a ruby gem, uses the git-svn under the hood but it allows to do conversion more smooth. I didn’t use svn2git for converting the CORE repo, but reading its sources I figured out how the git repo at github would be improved to add most important branches (1_9) and tags (2.0.0, 2.0.1). If it is really need I could add another labels. 

The full list of the svn tags are:

  1. 0_8_0
  2. 0_8_1
  3. 0_9_0
  4. 1_0_1
  5. 1_0_RC1
  6. 1_0_RC2
  7. 1_1
  8. 1_1_1
  9. 1_2
  10. 1_3_0
  11. 1_4_0
  12. 1_5_0
  13. 1_5_1
  14. 1_5_1@573
  15. 1_5_2
  16. 1_6_0
  17. 1_6_1
  18. 1_7_0
  19. 1_8_0
  20. 1_9_0
  21. 1_9_1
  22. 1_9_2
  23. 1_9_3
  24. 1_9_4
  25. 1_9_5
  26. 2.0.0
  27. before-refactoring
  28. liquibase-2.0-rc2
  29. liquibase-2.0-rc3
  30. liquibase-2.0-rc4
  31. liquibase-all-2.0-rc2
  32. liquibase-all-2.0-rc2@1543
  33. liquibase-parent-2.0-rc4
  34. liquibase-parent-2.0-rc5
  35. liquibase-parent-2.0-rc6
  36. liquibase-parent-2.0-rc7
  37. liquibase-parent-2.0.1
  38. modify-column-2.0-rc5
  39. modify-column-2.0-rc5@1686

Branches’ list:

  1. 0_8
  2. 0_9
  3. 1_1
  4. 1_9
  5. eclipse_ide
  6. next_version
  7. refactor_migrator
  8. TRY-M2

I will write separate post about the CONTRIB

I don think we have to leave the CONTRIB to the mercy of fate. If that it would make a negative impact at the liquibase’s appeal as a robust project. I don’t think about the certification, but a little notice about the compatibility is very useful. 

More if the API changes and internal changes of forthcoming versions will be fixed it would be great. Writing the compatibility test for every extension would be awesome.

Working on such kind of supporting/development using svn is more painful as with git.

Technically I suggest a separate repository for every CONTRIB subproject with its own branch/tag history. If someone (integrator?) want to have all the modules under one folder he/she can use git submodule facility. 


I have not forgotten about the thread. I’ve looked through the converted git repository and I think it looks good. 

Do you know how we can move the repository from where you have it to under ? I believe I could fork your repository, but from others looking for the original master, I want all liquibase forks to lead back to as the “original” rather than 

Do I just create a new repository under github/liquibase and then push my clone of olegtaranenko to the repository? Or does that still keep the reference back to the original origin?


I think I may have found it out. I created a new repository, and did a git rm origin and git add origin to the cloned oleg repository and did a git push. It appears to be pushing the repository up.

Given the size of it, I want to delete out the old .swf files. I am going to look into how to best do that tomorrow.


Currently liquibase/liquibase repository has only master branch and not 1_9 branch and tags. BTW I added 1.9.5, 1.9.4, 1.9.3 and 1.9.2 tag for historically reason. Let make so I will try to transmit current version of liquibase-CORE under liquibase account and you could rename it to the liquibase. 

there are no *.swf files in the repository. If are, the repository would be more as 200 MB