Subversion Is An Old Man's Tool.

As Joel Spolsky put it: "Distributed Version Control is here to stay, baby”. If you've read Joel's stuff, you know he has a way of making sense — a quality of writing which can be tough to find on the Internet. As a Git user, I can't say Joel converted me, but he did get me thinking about why I too hung on to familiar ol' Subversion long after it's obsolescence. Rather than boring you with that, herein lies a minimalist guide to getting started with distributed version control.

If you are wondering about the Git vs Mercurial (Hg) debate, don't bother. Both work well and can even be used in tandem. The focus here will be on Git because it has alphabetical priority, and Joel has already written Hg Init: a Mercurial tutorial.

For experienced developers, the hardest part about learning Git is unlearning Subversion or other legacy VCS. Here are a few things to keep in mind (if you get bored, just substitute "jedi" for "repository"):

• Any repository can be cloned.


• Any repository can be a master.


• Distributed VCS doesn't mandate distribution.


• Local changes: checkout, commit


• Remote changes: pull, push

A New Repository

Don't be put off the 'distributed' bit, git is perfectly happy to have just one folder — repository and working copy all rolled into one:

mkdir /srv/git/foo
cd /srv/git/foo
git init
# add some files
git add .
git commit -m'initial checkin'

So Git scales down nicely, but with shared repositories it is important to know that Git will grouse if asked to push changes to a destination where files are checked out. This problem is easily avoided with a bare repository, essentially a repository which cannot have files checked out locally:

mkdir /srv/git/foo
cd /srv/git/foo
git --bare init

Send in the Clones

Where git repositories already exist, new ones can be cloned; optionally, the new clone can be --bare:

# new working copy:
git clone ssh://user@gitserver/srv/git/foo
git pull

# bare clone:
git clone --bare ssh://user@gitserver/srv/git/foo
git pull

Go with the Workflow

Much of the Git workflow is straightforward, especially if your working copy was cloned from a (bare) master repository:

# get the latest changes
git pull

# make some changes
find . -type f -exec dd if=/dev/zero of={} count=1 \;

# oh crap! I just (sort of) Zeroed all my files
# no worries, just abandon the changes

git checkout .

# double check
git status

# make changes worth keeping
# ... then commit
git commit -a

# need to amend the last check-in message?
git commit --amend

# push local changes to master
git push

There's enough to jump in and get into trouble with git; to find out more, try the following resources:

• Git Documentation
• Git Tools & Hosting


• Why is it called "git"?

Linux Security: Denyhosts

If you've read my Open SSH series, perhaps even if you haven't, you are probably aware of the power SSH offers to those who know how to use it. There are many ways to protect the service from unauthorized usage, focusing on self-contained or single host solutions, one finds two common flavors: those which make use of the Linux kernel's packet filtering tools (netfilter and iptables), and those which rely on Wietse Venema's TCP Wrappers. Netfilter certainly offers power and flexibility, but this may be at the cost of simplicity and management ease. While no security measure ought to be implemented blindly, there is an undeniable benefit to simple measures which can be configured quickly and with little fuss — in this arena, TCP Wrappers stands tall.

Cloud Life: Kernel Upgrades

One thing not mentioned in EC2StartersGuide is how to apply kernel patches. Technically, this isn't currently possible in the Amazon cloud, which is to say that the boot loader (e.g. grub) within an EC2 instance cannot load an arbitrary kernel; nonetheless, official kernel updates are available via package updates, though cloud servers won't automatically load the latest installed kernel when booted.

Managing MySQL

Database management is one of those tasks where GUI tools can often be handy and occasionally critical. The history of Linux point-and-click tools for MySQL is a bit checkered, and prominently features MySQL Query Browser and MySQL Administrator, official tools formerly supported by MySQL. Early releases were buggy and crash-prone, but had progressed to merely flaky by late 2009, when MySQL announced they would pull the trigger on them in favor of MySQL Workbench. MySQL support for the GUI Tools Bundle officially ended in June 2010, but the tools are still available in Debian and Ubuntu repositories, while MySQL Workbench is conspicuously absent. While this may deter many users from test driving Workbench, they are missing out on a powerful tool for database management. Fortunately, MySQL publishes MySQL Workbench binaries.