Moving source code to GitHub?


I was just wondering if you have thought about moving the source code to a DVCS instead of Subversion? Provides for a much easier workflow for letting other developers help out.

If you think this is a good idea, I think GitHub is the best option. It has great features for collaboration and almost everyone has an account there, so you can get a lot of help fast. And if you need any help in the migration, just ping me :slight_smile:


Stig Kleppe-Jorgensen

I like the idea of using a distributed version control system.

I am not sure if git is the right choice. It has gathered a stout following, but it can be daunting to start using. In this respect mercurial offers a easier migration for subversion users. But I am interested if Nathan is willing to migrate away from a svn.


Anything is better than svn  But really, I have no experience with Mercurial, but as long as it is distributed, I am game.

Not sure you get the likes of GitHub, then, though…if we don’t just use GitHub’s Mercurial support.

I have been thinking of moving to github, partly from a chance for me to learn git and partly for the improved code committing processes we can use.

I am concerned that non-SVN could be a roadblock for many developers interested in committing code, but I know there are options related to having a svn repository that is based on a git repository. 

There are some changes I’m hoping to get in for a 2.0.2 release, evaluating the move to github is part of what I am considering for 2.1.

Anyone else have an opinion on svn vs git vs mercurial?


You can actually use a svn client against GitHub, see I have not tried it myself, so I am not sure how good it is. And for people wanting to use Mercurial instead of git, can use the hg-git plugin, see

Just so one can make an informed choice :slight_smile:



There is bitbucket by atlassian

When push comes to shove I would vote for git. Although the learning curve for git is steeper then the learning curve for mercurial, git seems to be more popular. There are a lot of good references on git to aid in the acceptance of a new version control system for liquibase.

As Stig points out there are ways to connect to a git repository via svn or mercurial. So nobody would get shut out if the source code for Liquibase would be hosted on github.


Thanks for the info on SVN and mercurial plugins, that is helpful. I agree that git would be the way to go. It seems more popular and I like that github is very much built around helping people contributing code to a project. 

I am WAY behind in answering forum questions, and have some bugs I would like to resolve for 2.0.2, but once that is out I will look at moving the code over.



 +1 for git, if it make sense. I could also share my experience about migration for my projects from svn to git.

Show stopper note: if svn project uses file’s non-ascii characters names git will wrong convert it. 

Regards, Oleg

You know my opinion on this matter, but just to be public about it: I would vote strongly for Git. Mercurial has its users, but in terms of community mindshare, there is no stopping Git at this point. It’s the system people are migrating to, the one it’s easier to get help with, the one more people are preferring. Of course those are all pragmatic reasons which do not address its technical merits, but it is either superior on its merits or close enough not to matter (depending on how persuasive any one person finds the technical arguments to be).

As for lack of Git knowledge being a barrier, I think the general trend is that the Git—and more specifically, the GitHub—model of social coding encourage contributions much more than SVN does. It doesn’t seem obvious why this would be the case, but it is a consistent message I am beginning hear from people who run open-source projects after having done the migration.

I would love for 2.1 to be hosted on GitHub, and I’ve love to help with the migration. 


Moving to a DVCS is a good idea. I personally use both Git and Mercurial and most of my Open Source stuff is on BitBucket. While considering Git, it probably also make sense to look at Git-Flow: