Short primer, importing a SVN repository into a GIT one

I wanted to convert parts of the Botlist project to GIT. Basically, I did just that. I saved the history from the Subversion repository and was able to import that into a new GIT repository. My entry will discuss the steps that I took to make that happen, also I work with several different remote machines so I hacked together a startup script for git-daemon.

Get GIT and install

I am working with an Ubuntu Dapper machine (yes, it is an older distro) and I didn't want to go through the hassle of using a very out of date version of git, so we are going to download the most recent git from kernel.org.

wget http://kernel.org/pub/software/scm/git/git-1.5.3.5.tar.gz
tar -xvf git-1.5.3.5.tar.gz

Pre configure and Installation

Actually, before running configure on the git source; you may need to get two
libraries.

On Ubuntu, I did the following:
  • sudo apt-cache search libsvn-core-perl
  • sudo apt-get install libsvn-core-perl
  • sudo apt-get install libcurl3-dev
In order for the git-svn to work, you will need the libsvn perl libraries. For working with http operations, you will need libcurl.

Run ./configure

At this point, you can start to build the git source; type ./configure at the command prompt and the subsequent make/install commands. Basically, standard steps for compiling and installing a typical linux source package.
  • ./configure
  • make
  • sudo make install
Git is installed, now get the subversion project (history)

Assuming git was built properly, you should be able to import a subversion
project. I suggest creating a directory and then have git create the .git repository information in that particular folder.

  • sudo mkdir -p /usr/local/var/gitscm/botlist.git
  • cd /usr/local/var/gitscm/botlist.git
  • sudo git-svn clone http://openbotlist.googlecode.com/svn/trunk/openbotlist/
At this point, you will see verbose output of git creating the botlist repository.
That is all that is needed to create a repository from subversion, notice that the svn (.svn) working directory folder is not included in your git project.

Running the git-daemon at machine startup

Unlike other linux daemons, setting up git-daemon is pretty simple. At least for running the git daemon server under the git protocol. Basically, git-daemon is a server for hosting git repositories and this particular server defaults to running on port 9418. GIT also supports hosting repositories through HTTP.

Run whereis git-daemon to find out where the executable is located. It is up to you how to pass the git-daemon arguments, I used a simple wrapper bash script and launched git from there.

BASE_PATH=/usr/local/var/gitscm
/usr/local/bin/git-daemon --reuseaddr --verbose --base-path=${BASE_PATH} --export-all -- ${BASE_PATH}

[End of Script]
Change the base-path path according to where you want to store your git repositories. In the script above, gitscm is just a regular directory. The subdirectories (for example, botlist) are actual git repositories (that contain the .git directory). Create a symbolic link in your init.d directory, something along the lines of this:

ln -s /usr/local/bin/git-daemon2 git-daemon2

With ubuntu, you can run update-rc.d to ensure that the git-daemon2 script gets launched at startup:

  • sudo update-rc.d git-daemon2 defaults

Run and Test

Now, you can start the git-daemon2 script
  • git-daemon2 &
  • git ls-remote git://127.0.0.1/botlist.git
  • To get the project, cd to some directory
  • git clone git://127.0.0.1/botlist.git
Resources

Comments

Post a Comment

Popular posts from this blog

Is Java the new COBOL? Yes. What does that mean, exactly? (Part 1)

Image
"If you want to know the past, look at your present. If you want to know the future, look at your present." -- Gautama Buddha Java is the new COBOL, whaaaat?     If you are software developer that mainly writes applications for the web; even if you aren't a Java/J2EE developer, you have probably heard the new meme circulating the web and blogosphere. "Java is the new COBOL" . Most blogs and technical writers regurgitate that statement and follow-up by saying that EJBs suck, and some companies are considering Ruby on Rails. I didn't really think much of these posts. I get the impression that a lot of these "managers" don't write any Java or COBOL code. They are really not highlighting the seriousness of the problem. COBOL development has remained stagnant for decades. Java may see the same problem in the future. The Pentagon/DOD has a trillion dollar COBOL problem because it is so difficult to change their ancient infrastructure. Anyon
Read more

On Unit Testing, Java TDD for developers to write

It has been a while, let's kick off 2017 with a blog entry. I have read and I am reading about four or five posts a day about unit testing. It really has been a long time obsession for me. I have moved past the technical and practical considerations on unit testing frameworks and done with the debates with "should you use Junit or Mockito or Karma?" I am more interested in the psychology of unit testing, who does it, likes it, hates it? It really is one of those easy to learn, hard to master concepts. For example, many many may play chess when they are young and can end up being horribly chess players most of their life, I am part of that majority. Unfortunately, I have never played chess and sat down for hours and tried to master it. I never see the common patterns or have a developed end game. I mostly just play with a knowledge of the basic rules. Following good unit testing practices within your software development shop is a lot like playing chess. It is easy to le
Read more

JVM Notebook: Basic Clojure, Java and JVM Language performance

Image
"Measure, don't guess. The primary goal of all performance tuning exercises should be maximize the end user experience given the resource constraints." [1] "It isn't so much a "farewell to the J" as an expansion of the platform opportunities Java provides. Sun's investment to power ongoing development of JRuby and Jython broadens the range and reach of Java, as a whole." -- Rick Ross Overview and JVM Languages    One of the exciting trends to recently emerge from the Java community is the concept of the JVM language. These technologies are all that you would expect them to be. They are implementations of languages that run on the Java Virtual Machine. Some are newly created and some are based on existing, more mature languages. JRuby, Jython are two JVM languages based on CRuby and CPython. Groovy, Scala, Clojure are three completely new JVM languages that were created to add new language features that weren't supported by the core Ja
Read more