Unintelligible

Wednesday, July 30, 2008

Migrating a Subversion repository to a remote Git repository

Migrating an existing SVN repository to git is pretty easy; here’s a quick step-by-step guide (and reminder to myself).

Before we start, let’s make sure git and git-svn are installed:

$ sudo apt-get install git git-core git-svn

1. Getting the code out of Subversion

First, use git-svn to get a copy of the remote Subversion repository you want to migrate. For instance:

$ git-svn clone --authors-file=git-svn-users.txt --stdlayout https://my.svn.repository.com/MyProject

A couple of words on these options:

  • clone gets a copy of the entire repository, including all commit history, tags and branches
  • –stdlayout tells git-svn that you have laid your SVN repository as per the SVN recommendations, namely with top-level folders for trunk, tags and branches. If not, you can specify the paths for these relative to the repository root using the –trunk, –tags and –branches switches respectively (instead of –stdlayout)
  • the –authors-file option allows you to map SVN users to git users, for the commit history; the file should be in this format:
    svnUserId = First Last

This process will take a little while, especially for large repositories. When that’s done, git-svn will have created a new MyProject folder containing the full repository.

We can verify its contents:

$ cd MyProject
$ ls -la 
$ cat .git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[svn-remote "svn"]
    url = https://my.svn.repository.com/MyProject
    fetch = trunk:refs/remotes/trunk
    branches = branches/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*

Note that the location of our remote SVN repository is stored in the .git/config - this allows git-svn to commit any changes you make back to the main SVN repository if you want to (how to do this is well explained in the introduction to git-svn for Subversion deserters).

2. Creating a remote git repository

However, our aim is to replace our existing remote SVN repository with a remote git repository; to do so, we first need to create an empty git repository on the remote machine, which we will then upload the repository we just created locally. This assumes that git-core is installed on the remote machine:

$ ssh me@remote-machine.com
$me@remote>: mkdir git
$me@remote>: cd git
$me@remote>: mkdir MyProject.git
$me@remote>: cd MyProject.git
$me@remote>: pwd
/home/me/git/MyProject.git
$me@remote>: exit

Note the output of pwd - this will be the path we will use to access the remote repository from our local box.

3. Configure the local repository

Now that we have created the remote repository, we can upload our local repository to its remote location. First, back on our local machine, we need to tell git where the remote repository is located:

$ git remote add origin ssh://me@remote-machine.com/home/me/git/MyProject.git

Here:

  • remote add: adds a remote location
  • origin: the name of the remote location

Next, we need to tell git who we are:

$ git config --add user.name "First Last"
$ git config --add user.email me@domain.com

Let’s have a quick look at our configuration:

$ cat .git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[svn-remote "svn"]
    url = https://secure2.svnrepository.com/s_zcrar70/MetisseV2
    fetch = trunk:refs/remotes/trunk
    branches = branches/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*
[user]
    name = First Last
    email = me@domain.com
[remote "origin"]
    url = ssh://me@remote-machine.com/home/me/git/MyProject.git
    fetch = +refs/heads/*:refs/remotes/origin/*

Note the user information and the remote location have been added to the config file.

4. Uploading to the remote git repository

That should be it - we’re ready to upload the local repository to the remote location. It’s as simple as:

$ git push origin master

This will upload the contents of the master branch to the origin remote repository. We will also want to upload any tags and branches from subversion:

$git branches -r
branch1
branch2
tags/tag1
tags/tag2
$git push origin branch1:refs/heads/branch1
$git push origin branch2:refs/heads/branch2
$git push origin tags/tag1:refs/tags/tag1
$git push origin tags/tag2:refs/tags/tag2

A note on the commands here:

  • git branches -r: list all remote branches
  • git push origin :/refs/heads/: push the local branch to the remote repository, creating a new remote branch of the same name
  • git push origin tags/:/refs/tags/: push the local tag to the remote repository, creating a new remote tag of the same name

5. Accessing our new remote git repository

The contents of our local git repository were retrieved from SVN; now that we’ve uploaded that to our new remote git repository, we can get rid of the intermediary local repository we were working on, and begin using with our remote git repository in earnest:

$ cd ..
$ rm -rf MyProject
$ mkdir MyProject
$ cd MyProject
$ git init
$ git config --add user.name "First Last"
$ git config --add user.email me@domain.com
$ git remote add origin ssh://me@remote-machine.com/home/me/git/MyProject.git
$ git pull origin master
$ git branch -a
* master
  origin/master
  origin/branch1
  origin/branch2
$ cat .git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[user]
    name = First Last
    email = me@domain.com
[remote "origin"]
    url = ssh://me@remote-machine.com/home/me/git/MyProject.git
    fetch = +refs/heads/*:refs/remotes/origin/*

That’s it! We’ve just pulled the master branch from our remote git repository, and at this stage, we are ready to start working with git locally. Note that when we ask git to tell us about all of the branches it knows about, it no longer mentions the SVN branches that we are no longer interested in.

We can now edit files, commit changes, and then push those changes to our remote repository; a good place for SVN users to start learning how to do this is the Git-SVN Crash Course

Note: if you have git-svn installed on the remote machine, you can use git-svn to clone the repository from SVN directly on the remote machine using the –bare option (which gets just the repository, without the files). You can then use git pull to get a local copy once the remote information has been set up; this involves less steps, and would likely be a little quicker. Unfortunately, I didn’t have access to git-svn remotely, or access to install it, so this wasn’t an option for me.

The following guides were helpful to me:
Setting up a new remote git repository - Toolman Tim

An introduction to git-svn for Subversion deserters
Converting a Subversion repository to git - Ruby Forums
Converting Subversion repositories to Git - Redline Software

posted by Nick at 9:02 pm - filed in linux  

Saturday, March 15, 2008

Dvorak keyboard in Ubuntu/Xubuntu

For my own reference, a couple of ways of setting up the Dvorak keyboard in Linux. In Gnome:

System > Preferences > Keyboard > Layouts tab > Add button > Dvorak

For a single terminal session:

loadkeys dvorak

Adding that line to .bashrc should result in it applying to all your terminal sessions. For all X sessions (including the GDM logon screen and Gnome), add Option "XbdLayout" "dvorak" to /etc/X11/xorg.conf as such:

Section "InputDevice"
  Identifier "Generic Keyboard"
  Driver "kbd"
  Option "CoreKeyboard"
  Option "XkbRules" "xorg"
  Option "XkbModel" "pc105"
  Option “XkbLayout” “dvorak,gb”
EndSection

This allows switching between the Dvorak and GB layouts by pressing both shift keys at once.

posted by Nick at 2:20 am - filed in dvorak, linux  

Monday, December 17, 2007

Vi! Vi! Vi!

I’ve been using Vim for about 4 months now, and I must admit that I’m not sure how I did without it. Modal editing seems like a natural paradigm to me (similar to lifting your hands off the keyboard to perform operations with the mouse, except without lifting hands from the keyboard :-), and the movement commands seemed intuitive and somehow logical, much easier than remember all the different keybindings Emacs has. Vim is a great text editor; however, it isn’t as well suited to more specific tasks, such as being an IDE or a document editor, as dedicated software such as IntelliJ IDEA or Word/OpenOffice are. The problem with those, in turn, is that text editing isn’t half as smooth as with Vim.

So, I was quite pleased when I stumbled upon this:

http://jvi.sourceforge.net/

A Netbeans module for Vi-like editing in Netbeans. I’ve been playing with it a bit and it definitely looks promising; this goes at least some way to resolving the IDE question, as I’ve found Netbeans to be great for Ruby/Rails and second only to IntelliJ as a Java IDE. For work, I’m thinking of splashing out on this:

http://www.viemu.com/

I’ve had a go with the demo and it works great. They have a version for Word/Outlook too, which is definitely very enticing - even though I already find editing text with Vim a lot more efficient than with a traditional editor, I still feel like I could be quite a bit more productive, and the more I get to practice, the easier this should hopefully become. Now if only I could find an equivalent for Open Office and Thunderbird…

posted by Nick at 11:15 pm - filed in linux, windows  

Wednesday, June 6, 2007

WPA using the WPC54G v3 wireless card in Ubuntu Feisty

OK, this is more of a pense-bete to myself than anything else. To get WPA v1 working under Xubuntu Feisty with my WPC54G v3 wireless card, I used the following guides:

To install the wireless card: http://ubuntuforums.org/showthread.php?t=197102
To add WPA: http://ubuntuforums.org/showthread.php?t=202834

The step by step version is as follows.

Installing the wireless card
1. Download this file to the desktop: http://ubuntuforums.org/attachment.php?attachmentid=30908&d=1177587401

2. Extract the file and run the setup:

cd ~/Desktop
tar -xf bcm4318*.tar.gz
sudo ./ndiswrapper_setup

At this point, the wireless card should be installed correctly. This can be verified as follows:

3. This should display some info about your wireless network interface, probably called ‘wlan0′

nick@nick-laptop:~$ iwconfig
wlan0     IEEE 802.11g  ESSID:xxx
Mode:Managed  Frequency:2.437 GHz  Access Point: 00:14:BF:3D:xx:xx
Bit Rate=54 Mb/s   Tx-Power:25 dBm
RTS thr=2347 B   Fragment thr=2346 B
Power Management:off
Link Quality:73/100  Signal level:-49 dBm  Noise level:-96 dBm
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:0   Missed beacon:0

4. This should return a list of wireless networks in your vicinity, including the one you want to connect to:

nick@nick-laptop:~/Desktop$ iwlist scan
wlan0     Scan completed :
Cell 01 - Address: 00:11:50:84:1F:F4
ESSID:"espresso"
Protocol:IEEE 802.11g
Mode:Managed
Frequency:2.462 GHz (Channel 11)
Quality:60/100  Signal level:-57 dBm  Noise level:-96 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s
6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
36 Mb/s; 48 Mb/s; 54 Mb/s
Extra:bcn_int=100
Extra:atim=0

Adding WPA
1. From the wireless access point, make sure of the following:

  • WPA security is enabled using WPA-Personal Shared Key (WPA-PSK)
  • The WPA encryption algorithm is set to TKIP (not AES)
  • You have a note of the SSID (wireless network name) and the PSK (shared key) - here, we will use ‘expresso’ for the SSID and ‘hohohoho’ as an (insecure) PSK example

2. Make sure wpasupplicant is installed:

sudo apt-get install wpasupplicant

3. Convert your PSK as follows:

wpa_passphrase 'your essid' 'your ascii PSK key'

In our example:

nick@nick-laptop:~/Desktop$ wpa_passphrase 'expresso' 'hohohoho'
network={
ssid="expresso"
#psk="hohohoho"
psk=57245dfdd9663e8c9792bfe9a15f41f07cc34a57bd1fc91f2820e3302dbfa7d1
}

4. Open /etc/network/interfaces for editing:

sudo mousepad /etc/network/interfaces

5. Find the lines that look as follows:

auto wlan0
iface wlan0 inet dhcp

Replace as follows:

auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-ssid <your ssid>
wpa-ap-scan 1 #this assumes SSID broadcast is enabled - set to 2 if SSID broadcast is disabled
wpa-proto WPA
wpa-pairwise TKIP
wpa-group TKIP
wpa-key-mgmt WPA-PSK
wpa-psk <your hex key>

In our example:

auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-ssid expresso
wpa-ap-scan 1
wpa-proto WPA
wpa-pairwise TKIP
wpa-group TKIP
wpa-key-mgmt WPA-PSK
wpa-psk 57245dfdd9663e8c9792bfe9a15f41f07cc34a57bd1fc91f2820e3302dbfa7d1

6. Make sure any ethernet cables are unplugged, and restart the network interfaces:

sudo /etc/init.d/networking restart

At this point, WIFI should be working with WPA enabled… For further reference regarding different WPA configurations, the WPA guide on the Ubuntu forums is excellent.

posted by Nick at 12:49 am - filed in linux