Month: August 2009

So I have a few projects on SourceForge, but they’re all hosted via SVN. With all this distributed version control going on I thought I would like to get in on the action. I thought about moving to github, but what happens in 5 or 10 years when I want to move on to another revision control software? The name has a limited life expectancy. Anyway so I wanted to switch so I researched alot, this is the best information I found and this blog entry is basically a rehash specific to SourceForge (Because I didn’t find any good SourceForge specific information).

Note: For this tutorial you will want to change all occurrences of USERNAME to your user name for example “pilkch”, PROJECTNAME to your project name for example “breathe” and YOURFULLNAME to your full name for example “Chris Pilkington”.

First of all we need to download git and git-svn:

su
yum install git git-svn

Now we are going to create our repo directory for holding our repositories:

cd ~
mkdir repo

Create a users.txt file to map our subversion users to git users:

users.txt

USERNAME = YOURFULLNAME <USERNAME@PROJECTNAME.git.sourceforge.net>

As the other article says, we basically check out a svn directory as a git repository:

cd repo
mkdir PROJECTNAME_from_svn
cd PROJECTNAME_from_svn
git svn init http://PROJECTNAME.svn.sourceforge.net/svnroot/PROJECTNAME/PROJECTNAME --no-metadata
git config svn.authorsfile ../users.txt
git svn fetch

Check that worked (Just read the last few changes to make sure svn history is present, you can hit spacebar to scroll back a page of history or two just to make sure):

git log

From now on we can use git commands, first of all want to create a copy of the git-svn repository:

cd ..
git clone PROJECTNAME_from_svn PROJECTNAME

PROJECTNAME/ now contains our “clean” repository and PROJECTNAME_from_svn can be deleted if you like. We now just need to add and push our local repository to the remote location:

cd PROJECTNAME
git config user.name "YOURFULLNAME"
git config user.email "USERNAME@users.sourceforge.net"
git remote rm origin # This may not be necessary for you
git remote add origin ssh://USERNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/PROJECTNAME
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
git push origin master

Now to check that this is working you can browse to the git page of your SourceForge project and there should be data in your repository. And we can clone our repository back again to check that everything is working.

git clone ssh://USERNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/PROJECTNAME

You may also want to ignore certain types of files, place a file called .gitignore in the root directory of your project and fill it with the patterns you want ignored:

.gitignore

.DS_Store
.svn
._*
~$*
.*.swp
Thumbs.db

Now when we want to update we can do:

git commit -a -m "This is my commit message." # All changes to the local repository need to be committed before we try merging new changes
git pull # Grab any changes from the main repository

Committing is slightly different:

git add .gitignore # For example we might want to add our new .gitignore file
git commit -a -m "This is my commit message." # Note: Your commit has now only been staged, it is not in the main repository yet
git push # Now it is pushed into the main repository

The last step is to remove your svn repository which for SourceForge is as simple as unchecking a checkbox on the Admin->Features page.

$ ls -l
total 24
drwxrwxr-x   ...   thisisadirectory
-rw-rw-r--   ...   thisisafile
lrwxrwxrwx.  ...   thisisalink -> /media/data

We know what the rwx fields are but what about d, – and l? Ok, those are pretty obvious too, here is a list of the more obscure ones because I always forget.

d Directory.
l Symbolic link.
– Regular file.

b Block buffered device special file.
c Character unbuffered device special file.
s Socket link.
p FIFO pipe.
. indicates a file with an SELinux security context, but no other alternate access method.

s setuid – This is only found in the execute field.
If there is a “-” in a particular location, there is no permission. This may be found in any field whether read, write, or execute field.

The file permissions bits include an execute permission bit for file owner, group and other. When the execute bit for the owner is set to “s” the set user ID bit is set.
This causes any persons or processes that run the file to have access to system resources as though they are the owner of the file. When the execute bit for the group is set to “s”,
the set group ID bit is set and the user running the program is given access based on access permission for the group the file belongs to.