The other day at work, I found myself needing to see a list of Subversion commits by a specific user. I spent a few minutes looking at the svn log help, but nothing seemed to be designed to show commits by user. It took me a while to find something to do the trick, but this is it:
svn log | sed -n '/username/,/-----$/ p'
Gotta love sed!
Today I found myself trying to figure out how to make a terminal window stay permanent on my desktop or dashboard on OSX, similar to what I've done in the past with Linux. I just wanted to have the terminal window monitoring things in the background for me. Actually, all I wanted to do was keep track of when my local working copy of our Subversion repository was out of sync. I wanted a solution that would keep out of my way, but I also wanted it to be easy.
My search for a solution seemed short-lived when a Google search suggested a dashboard widget for the Terminal application. The problem with it was that the download server was dead or simply blocked by my company's Internet filter. One way or another, it wasn't long before I went in search of another solution.
At that very instant, I received a Growl notification from some program. That's when it dawned on me--I could tell Growl to tell me when my working copy was out of sync. I had done stuff like that in the past, so I set out to write my solution. This is what I came up with:
#!/bin/bash MY_BOX=[my IP address] DEV_ROOT='/path/to/svn/working copy' cd $DEV_ROOT MY_REV=`svn log --limit 1 | awk '/^r/ {print $1}' | sed 's/[^0-9]//g'` SVN_REV=`svn log --limit 1 -r HEAD | awk '/^r/ {print $1}' | sed 's/[^0-9]//g'` if [[ $MY_REV != $SVN_REV ]]; then ssh username@$MY_BOX "growlnotify -s -d47111 -n 'iTerm' -t 'Out Of Sync' -m 'Your working copy is out of sync. Repository is at revision $SVN_REV, and your working copy is at $MY_REV.'" fi
Now, a little bit about my environment. As I've mentioned before, all of our development really takes place on Linux-powered virtual machines. We simply use our Macs as the system to interact with those virtual machines. That is why there's the ssh line in that script.
Basically, this script just checks the most recent revision in your local working copy. Then it checks the latest revision in the repository itself. It compares the two revision numbers, and if it finds a difference, it will SSH into my OSX box to send me a Growl notification. On the OSX side, I have Growl and growlnotify installed. Here's a summary of the options to growlnotify:
This is a fabulous little reminder to me. I have it set up as a cronjob that runs every minute on my Linux-powered development virtual machine. Hopefully this will help others!
Some of you may well know that I was previously an subversion user, more out of comfort than necessity. SVN was the first version control system that I became well acquainted with, so it just seemed like a natural choice for me when I thought I needed version control.
Several months ago I read a blog article by a buddy, in which he briefly discussed Mercurial. I had been meaning to give some distributed version control systems a shot after some disasters related to the centralized nature of SVN. This blog article prompted me to take a stab at Mercurial and some others.
Within a few days I was sold on Mercurial. I won't go into details simply because I'm not one for religious wars that way. Let's just say that Mercurial seemed to be perfect for my wants and needs.
There were, however, a few things about using Mercurial that I miss from the SVN world. One such thing is that you can update several "working copies" of something in SVN with a single command. For example, I keep a lot of my 3rd party Django applications in one directory. Many of these applications use SVN. Sometimes I'll just run a command like this:
svn up /path/to/third/party/apps/*
Each project that uses SVN will automatically be updated without much fuss with such a command. However, with Mercurial, it appears that you need to be in an actual Mercurial repository in order to update it. There are extensions to get around this problem, but I was looking for something a little different.
Since I use Linux almost exclusively, I didn't feel bad about just using the power within to do the work. The following command does everything I need it to:
find -name ".hg" -type d | xargs -t -i bash -c "(cd {}; hg pull; hg up)"
This command finds any directories called .hg anywhere under your current location on the filesystem. Any matches will be used in the command at the end: cd {}; hg pull; hg up
So far I haven't had any problems with this command, but your mileage may vary. To make things even easier, I made an alias for this rather long command:
alias hgupall='find -name ".hg" -type d | xargs -t -i bash -c "(cd {}; hg pull; hg up)"'
I put that line in my ~/.bashrc script, which is executed each time I log into my computer. With that in place, all I need to do is something like this:
cd /path/to/third/party/apps hgupall
And the aliased command handles the rest. Pretty slick stuff. Hooray for Mercurial and Linux!
It's been a while since I wrote a blog article, so I'm using this one-liner as an excuse. In case you're new here, I do a lot of Python development. In the world of Python, you need to have a special file in a directory before you can use Python code within that directory. Yeah, yeah... that's not exactly the clearest way to explain things, but it'll have to do.
This special file is called __init__.py. Having this file in a directory that contains Python code turns that directory into what's called a "python package." We like Python packages. They make our lives so much fun!
Anyhoo, I was working on a project last night, and I wanted to create a bunch of placeholder directories that I plan to use later on. I plan on keeping Python code in these directories, so putting the special __init__.py file in them is what I was looking to do. I didn't want to have to create the __init__.py file in each directory manually, or copy/paste the file all over the place, so I investigated a way to do it quickly from the command line.
One of my buddies brought an interesting command to my attention recently: xargs. I had seen it before in various tutorials online, but I never bothered to learn about it. This seemed like as good a time as any, so I started playing. The result of my efforts follows:
find . -type d | xargs -I {} touch {}/__init__.py
What it does is:
Turns out that xargs can be used for all sorts of good stuff. My friend brought it up as a way to get rid of those nasty .svn directories on his path to "Mercurial bliss."
find . -name ".svn" -type d | xargs -I {} rm -Rf {}
How beautiful!
With all of the hype that git has been receiving lately, I started playing with it a while back to see if it suited me and my wants/needs. I found it to be an interesting utility. I won't go into any details simply because I'm not really all that knowledgeable about all the ins and outs of version control systems, but I will say that I have decided I like it. I'm still not sure whether I prefer GIT over SVN or SVN over GIT.
My problem is that basically all of my projects are based on SVN repositories. I don't want to have to start up a new GIT repository for each of my past projects. Fortunately, there is an interface for GIT to use SVN repositories called git-svn. I use this utility primarily on my EeePC because it saves a good amount of space on my small disk (the git-svn versions of the working copies are typically about half the size of their svn counterparts). Sometimes it's a little wacky, but it works well enough for my needs.
I started using this git-svn utility on a Debian-based distribution. That meant it was insanely simple to get up and running: sudo apt-get install git-svn. I recently installed Slackware 12.2, and I was surprised to find out that the git-svn utility wasn't immediately available to me.
I did some googling to see if others had encountered the same problem. There were several accurate hits, but I couldn't quite find the solution I needed. In the end, I finally got things working. The following information describes what I did to achieve this monumental success.
The first roadblock that I encountered, obviously, was finding out that git-svn didn't work on my shiny new Slackware installation. After doing a bit of research, I learned that I could substitute the familiar git-svn command with git svn and continue using it as I previously had.
Once I learned about git svn and tried it out, I got a nasty error about Alien/SVN. I've lost track of the original error, and for that I apologize. Doing a little bit of research led me to execute this command as root:
cpan Alien::SVN
I'm not sure exactly whether that step is required, but you might as well do it :).
Next, I downloaded a couple SlackBuilds to create my own Slackware packages suited for my computer.
For each SlackBuild, you must download the original source code along with the actual SlackBuild itself. For example, when retrieving the necessary files for swig, I must download both swig-1.3.35.tar.gz and swig.tar.gz from the link specified. Here are some example commands, which should be run as root:
mkdir -p ~/downloads/slackbuilds; cd ~/downloads/slackbuilds wget http://slackbuilds.org/slackbuilds/12.2/development/swig.tar.gz tar zxf swig.tar.gz cd swig/ wget http://downloads.sourceforge.net/swig/swig-1.3.35.tar.gz ./swig.SlackBuild installpkg /tmp/swig-1.3.35-i486-1_SBo.tgz
The commands above should create a new directory in /root/ called downloads/slackbuilds. Next, the SlackBuild for swig will be downloaded and extracted, after which the swig source code will be downloaded. The SlackBuild is executed, rendering an installable Slackware package. Finally, the package is installed onto the system.
The process is basically the same for the subversion-bindings SlackBuild. On my system, however, I had to modify the stock SlackBuild slightly. I didn't install Apache on my EeePC because I don't use it and it would just be taking up space. When I tried to execute the SlackBuild for subversion-bindings straight from the archive, it complained about a missing apxs file, which has something to do with Apache.
To avoid the error, I modified the subversion-bindings.SlackBuild script to ignore the apxs thingy. The original ./configure section looked like this:
CFLAGS="$SLKCFLAGS" \ ./configure \ --prefix=/usr \ --mandir=/usr/man \ --enable-shared \ --disable-static \ --with-apr=/usr \ --with-apr-util=/usr \ --with-apxs=/usr/sbin/apxs \ --with-neon=/usr \ --with-zlib=/usr \ --with-pic \ --with-ssl \ --build=$ARCH-slackware-linux
I just removed the line that says --with-apxs=/usr/sbin/apxs \ and ran the SlackBuild script again. Worked like a charm.
At this point everything appeared to be able to work properly. Running git svn from the command line no longer spit out that nasty error I mentioned earlier. Instead it gave me the options I would expect to see.
That's when I tried to update an existing working copy of an SVN repository. It gave me this error:
$ git svn rebase Authentication realm: <http://special.domain.com:80> Subversion - code Password for 'myuser': Can't locate Term/ReadKey.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.10.0/i486-linux-thread-multi /usr/lib/perl5 /site_perl/5.10.0 /usr/lib/perl5/5.10.0/i486-linux-thread-multi /usr/lib /perl5/5.10.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.10.0 /i486-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5 /vendor_perl .) at /usr/libexec/git-core/git-svn line 3071.
That's not very nice, now is it? The solution was fairly simple: install Perl's Term::ReadKey module. As root, execute the following command:
cpan Term::ReadKey
After doing that I was able to happily update my working copy and move on.
I don't envision that this article will be the all-knowing, all-powerful resource for how to use git-svn on Slackware, but I sure hope it will help some other folks who run into the same problems as me.
Being the Django and Python zealot that I am, I often find myself trying to convert those around me to this awesome development paradigm. Once I break them, these people often ask me a lot of questions about Django. Over the past few months I've noticed that one of the biggest sticking points for people who are new to Django is actually getting it up and running to begin with. In response, this is the first in a series of articles dedicated to getting Django up and running.
The Django Web site describes Django as "a high-level Python Web framework that encourages rapid development and clean, pragmatic design." Basically, Django is just about the most amazing thing for Web development. I have tinkered with several different Web technologies, but nothing seems to even come close to what Django can do for me.
Python is a programming language used in numerous aspects of computing these days. It has a very simple yet powerful syntax. It's an easy language for beginners to pick up, but it provides adequate levels of power for the more experienced developers out there. If you have never programmed anything before, or you have dabbled with something like BASIC, Python should be fairly straightforward. If you are a programming veteran, but have only worked with languages like C, C++, Java, etc, you might struggle a bit with the syntax of the language. It's not difficult to overcome the differences in a couple hours of hands-on development.
Let's get started.
Having Python installed is critical--Django does not work without Python. I'm guessing that you're relatively familiar with the procedures for installing software packages on your particular operating system. However, I will share a few notes to point you in the proper direction if you're lost. If nothing else, just head over to the Python download page to download anything you need to install Python. I whole-heartedly recommend using the latest stable version of Python for Django, but you should be able to get by with as early a version as 2.3.
Simply grab the latest version of the Python installer. It is currently version 2.5.2. Once the installer has downloaded successfully, just run through the installation wizard like any other setup program.
Recent Mac OS X computers come with Python pre-installed. To determine whether or not you actually have it, launch the Terminal (Applications > Utilities > Terminal) and type python -c "import sys; print sys.version". If Python is already installed, you will see the version you have installed. If you have a version that is less than 2.3, you should download the newest version. If you don't have Python installed, you will get a "command not found" error. If you're in this boat, just download the latest version of the Python Universal installer and install it.
Most Linux distributions also have Python pre-installed. Just like with Mac OS X, you can check to see by opening up a terminal/konsole session and running the command python -c "import sys; print sys.version". If you have Python installed, you will see its version. If you get an error message when running that command, or you have a version earlier than 2.3, you need to download and install the latest version of Python.
If you're running a Debian-based distribution (like Ubuntu, sidux, MEPIS, KNOPPIX, etc), you can probably use sudo apt-get install python to get Python. If you're running an RPM-based Distribution, you can probably use something like Yum or YaST to install Python.
A sure-fire way to install Python on any Linux system, however, is to install from source. If you need to do this, you simply:
(I've only installed Python from source one time, so I might be wrong)
Generally speaking, if you didn't have Python installed before starting this tutorial, you will need to setup your PYTHONPATH environment variable. This is a variable that lets Python know where to find useful things (like Django).
You may also need to add the python executable to your PATH. If you can successfully run python from a command prompt window, you don't need to worry about it.
If you can't run python from a command prompt, follow the procedure above, but use the PATH variable instead of PYTHONPATH. PATH most likely already exists, so you just need to append/prepend the existing value with something like C:\Python25\ (again, this might need to change depending on where you installed Python)
Your PYTHONPATH should already be setup for you.
Usually you just need to edit your ~/.bash_rc script to setup your PYTHONPATH environment variable. Go ahead and open that up in your preferred text editor and make sure there's something in it like:
export PYTHONPATH=/usr/lib/python2.5/site-packages:$PYTHONPATH
Save any changes necessary and run the following command:
source ~/.bash_rc
This will take care of updating your current session with any changes you made to your ~/.bash_rc.
Once you have Python and have verified that you have version 2.3 or later, you are ready to install Django. Currently, the latest stable release is 0.96.1, but this is grossly out-dated. Django 1.0 will be released on September 2nd 2008, so the "unstable" copy of Django is pretty close to what 1.0 will have to offer. There are some incredibly useful improvements in the unstable version that I don't think I could do without anymore, so that's what I'll talk about installing here.
First, you need to have a subversion client. On Windows, the most popular one is called TortoiseSVN. On Mac OS X, I have played with a few, but I think Versions is a pretty decent one. Linux also has several to choose from, but if you're using Linux, you're probably going to use the command line anyway (right?).
For brevity, I will just use the subversion commands necessary to accomplish this task (instead of discussing all GUI interfaces to subversion).
The exact location that Django should be installed differs from system to system, but here are some guidelines for typical setups:
If you want a definite location, run the following command:
python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"
Once you know that location, go there in your command prompt or terminal session. Then execute this command svn co http://code.djangoproject.com/svn/django/trunk/django django. You will see loads of output, showing all of the files that you are downloading as you install Django.
As soon as that process completes, you should run python -c "import django" to make sure everything worked properly. If the command doesn't display an ImportError, you're good. Otherwise, you need to try again.
Once you can successfully import django, you might want to make sure you can run the django-admin.py script that comes with Django.
This process is very similar to what we did with the PYTHONPATH environment variable earlier.
You can run a command similar to this:
sudo ln -s /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/bin/django-admin.py /usr/local/bin
...On Linux
If you have "root" privileges on your Linux system, you can execute a command like:
sudo ln -s /usr/lib/python2.5/site-packages/django/bin/django-admin.py /usr/local/bin
If you don't have "root" privileges, you can setup your own /usr/local/bin:
mkdir ~/bin
Make sure your ~/.bash_rc contains something like:
export PATH=$HOME/bin:$PATH
Then update your current session with any changes you made to ~/.bash_rc by running this command:
source ~/.bash_rc
And that should do it! Now you should be ready to get started with Django.
Feel free to leave a comment if you're having problems installing Django. Good luck!
Check out Installing Django on Shared Hosting.
In this tutorial, I assume that you have access to a Linux machine on which you plan to create the repository. I have never tried to create a repository on Windows or Mac, but perhaps in the future I will. I am doing this on a Slackware 10.2 machine with subversion 1.3.2. Version differences shouldn't have a great effect on the validity of the steps outlined here.
If you haven't already installed subversion, you can download it from http://subversion.tigris.org/. You can download the svn package for a variety of platforms. If you download the source package, you should simply have to do the following as root:
Note: these are the general steps for installing a package from the source; they may be slightly different with svn.
Next, choose a place for your server to keep track of all of the changes to your project. Try a place like /var/svn or /home/[your_username]/svn. I would recommend creating a folder specifically for the repository.
Once you're in the directory in which you wish for your svn repository to reside, type the command svnadmin create repo or you can type the full path to be certain svnadmin create /var/svn/repo. This will create the repository.
I do most of my development on my local area network, so I haven't created a repository that can be used over the Internet. I would imagine that it's pretty similar to what we do to create a repository for your LAN. Choose a project to import into your repository and navigate to the folder that the project is in. For example, if I have a project called Foo in /var/www/htdocs/foo, I would go to /var/www/htdocs. Next, use the command svn import to pull your project into the repository. For our Foo project, we would use the command svn import foo svn://localhost/var/svn/repo/foo -m "Initial Import". This will create a new folder in our repository at /var/svn/repo called foo (/var/svn/repo/foo). Our project files will put crammed into that directory for tracking.
In order to be able to save your changes to our repository, we have to checkout the project again from the server. This is a pretty simple step, but it is critical. Even though we imported our project already, that folder remains untouched. SVN will not know how to handle the updates unless we checkout the project from the svn server. So, we proceed to checkout by removing or renaming /var/www/htdocs/foo and typing svn checkout svn://localhost/var/svn/repo/foo /var/www/htdocs/foo. This will place some hidden folders in each of the directories in your project. These hidden folders keep track of your local changes so that svn will know how to merge your changes with those of other developers.
When you've made some changes that you want to save, you can send them out by typing svn commit /var/www/htdocs/foo. This command knows how to get to the server to save the changes, since the project was checked out from the repository.
Sometimes you'll need to get changes that other developers have made, or revert back to a version of your project that didn't have as many problems. You can do this using the svn update command. If you're already in /var/www/htdocs/foo, you can type svn update and it will update files that have been changed in the repository since you last updated. If you're looking to get an older version of your project, you can type svn update -r PREV or a revision number in place of PREV.
Remember, these are just the basics of using SVN. You can do many amazing things with this utility. I actually did all of this as I was writing this article, so I'm sure that it works.