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 Therefore, I changed my stance and want to do the github conversion now.
My end goals are:
Having the official liquibase repository at github/liquibase
Me understanding how the process conversion process works
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.
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 (https://github.com/svenax/svn2git). 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.
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.
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 github.com/liquibase/liquibase 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.
Therefore, I changed my stance and want to do the github conversion now.