Closer To The Ideal

Joel Spolsky convinces me that Mercurial is better than Subversion.

In that podcast, I said, “To me, the fact that they make branching and merging easier just means that your coworkers are more likely to branch and merge, and you’re more likely to be confused.”

Well, you know, that podcast is not prepared carefully in advance; it’s just a couple of people shooting the breeze. So what usually happens is that we says things that are, to use the technical term, wrong. Usually they are wrong either in details or in spirit, or in details and in spirit, but this time, I was just plain wrong. Like strawberry pizza. Or jalapeño bagels. WRONG.

Long before this podcast occurred, my team had switched to Mercurial, and the switch really confused me, so I hired someone to check in code for me (just kidding). I did struggle along for a while by memorizing a few key commands, imagining that they were working just like Subversion, but when something didn’t go the way it would have with Subversion, I got confused, and would pretty much just have to run down the hall to get Benjamin or Jacob to help.

I do not enjoy doing merges of any kind in Subversion. Normally, when I get some code stable enough for release, I then abandon that line. I’ll do emergency bug fixes, but no further work. Instead, I start a new Subversion project, and all future work happens in that new project. Clearly, this is not the way version control is suppose to work. So I’m intrigued that Mercurial might fix the problems with Subversion.

3,500 websites got hacked because they had .svn folders on the live site. The really shocking thing is that Apache.org was one of the sites that got hacked:

A Russian security group has posted a detailed blog post(translation here) about how they managed to extract the source code to over 3,300 websites. The group found that some of the largest and best known domains on the web, such as apache.org and php.net, amongst others, are vulnerable to an elementary information leak that exposes the structure and source of website files. A web surfer is able to extract this information by requesting the hidden metadata directories that popular version control tool Subversion creates.

The actual ‘exploit’ itself has been well known for a long time. It is the fault of the server administrator or developer, rather than the fault of a particular application, since the working metadata directories in Subversion are only required for working copies of code. What is surprising is just how prevalent the problem is – and who it affects. Finding version control metadata directories is as simple as looking for ‘.svn’ or ‘.cvs’ folders within web paths, for example: http://www.test.com/.svn/.

For god’s sake, people, use the export command:

The Subversion Export action copies versioned files from a working copy or the repository, to another directory, allowing you to distribute the files without the .svn directory.

We’ve been using Springloops for a long time, which hosts our Subversion repositories. It has an auto-deploy feature that we rely on – every time we commit, it auto-deploys our files to our dev server. I’m fairly sure that Springloops auto-deploy feature is simply a script that hooks to the post_commit event and which then calls ‘export’ on the files you’ve just modified. I’m guessing I could write a similar script in an hour. This is the right way to deploy files from Subversion to your site. The wrong way is to treat you live site as a working copy of your repository and have it run the ‘update’ command every time the post_commit event fires. The problem with this approach is exactly what the article above describes – you can get hacked.

If you decide you absolutely need to have your site be a working copy of your repository,
the Subversion FAQ also demonstrates how to protect your site:

Add this to your httpd.conf:

# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch “^/.*/\.svn/”>
Order deny,allow
Deny from all
</DirectoryMatch>

Git handles merges better than Subversion:

Subversion has worked for us up until now on the project, but it is falling short of meeting our process and productivity needs. Without effective merging, branches won’t be used no matter how cheap they are to create. The only Subversion branches we have ever created have rarely stayed in sync with upstream and always led to dramatic merging ceremonies, worries about regression and code loss. To make a long story short, Subversion supports parallel development, but makes it so difficult to use effectively that you are better off avoiding it altogether.

Git handles our roughly 500,000-line Enterprise Java code base with ease. It is faster for one developer to git svn clone and then have his peers git clone than it is for each developer to checkout simultaneously from Subversion. Once done it gives every developer on the team offline access to the entire project history. The offline access allows developers to do complex historical comparisons that would be slow enough in Subversion to discourage developers from doing them. Git not only makes certain reporting operations fast, it makes them practical and productive to use.

This has often tripped me up: I copy a folder (which is under version control) to another location and all the”.svn” files get copied too. So this is useful: Scott Meves posts a trick for recursively clearing out the “.svn” files.

A while back I asked for advice about using Subversion to track a Symfony project. Scott Meves points to this informative article.

My normal workflow goes like this:

1.) I edit files on my local machine

2.) I commit the files to Subversion, which means Springloops, for us.

3.) On every commit, Springloops automatically deploys the files to our development server.

4.) I refresh my browser to see how the changes I’ve made look on the server.

This gets a little complicated when working with Symfony. Lots of files are auto-generated on the server, then I need to scp them to my local machine.

How can I get hundreds of new files, scattered among dozens of new directories, into Subversion? The “svn add” command will work recursively the first time you add a directory to your repository, but if you then add several dozen new directories to that top level directory, and if you then try to run “svn add” again, Subversion tells you that the directory is already under version control.

What’s needed is a reliable way to recursively add things to Subversion. (This isn’t a problem on Windows, because the TortoiseSVN client is good about recursively adding files. But it is a problem on Linux.)

So I am very glad that I found this script:

#!/bin/bash
echo ""
echo "Here's what we're going to do:"
echo " "
echo "Add the following files"
echo "-----------------------"
svn status | awk '/^?/ {print $2}'
echo " "
echo "Remove the following files"
echo "--------------------------"
svn status | awk '/^!/ {print $2}'
echo " "
echo "Check in the following modified files"
echo "-------------------------------------"
svn status | awk '/^M/ {print $2}'
echo " "
echo "Proceed with commit? [yn]"
read answer
if [ "$answer" = "y" ]
then
    echo " "
    echo "Adding the following files"
    svn status | awk '/^?/ {print $2}' | xargs svn add
    echo " "
    echo "Removing the following files"
    svn status | awk '/^!/ {print $2}' | xargs svn remove
    echo " "
    echo "Committing changes to repository"
    svn commit
else
    echo " "
    echo "Commit cancelled"
fi

echo " "
echo "Want to check for updates? [yn]"
read answer
if [ "$answer" = "y" ]
then
    svn update
else
    echo " "
    echo "Update cancelled"
fi

Just save this into a file at the root level of your project, and then call it from the command line when you want to commit stuff recursively.

I was pointed to this script from the Symfony forums.

We rely on Subversion to keep track of every change we make to our projects. Rather than host Subversion ourselves, we rely on Springloops.

We love Springloops. They have a great, easy to use interface, and they have a great deploy option that we’ve come to rely upon.

In fact, at this point, there are only two outside services that have proven worthwhile enough that we pay good money to use them each month.

One is Springloops.

The other is Basecamp.

Springloops helps us manage our code (HTML, CSS, images, PDFs, etc). Basecamp helps us manage our projects.

We do have one minor annoyance with Springloops – apparently because it is based in Poland, it doesn’t take credit cards, only PayPal payments. And they have consistently messed up the auto-billing of our PayPal account, so that we had to go in and pay manually, so as not to end up with an unpaid bill.

So, that leaves us somewhat curious about the competition: Beanstalk. Has anyone had much experience with them? If so, what do you think?

By the way, we used Unfuddle for one project. Not our favorite. It is ambitious, and tries to offer a bit of everything – ticket tracking, milestones, hosted Subversion, etc. Like a lot of projects that try to do everything, it comes up a bit short. For Subversion, we prefer the simplicity of Springloops. For project management, we prefer Basecamp.