I used to use subversion and svnmerge a lot, and there’s just one thing I miss about it. Now svnmerge is a tool to bolt on merge tracking to svn, and gits merge tracking is vastly better in many ways. But the one thing that svnmerge allowed me to do that was cool and doesn’t have a real equivalent in git is to block commits

I’m used to how svn export works, and have used this in a number of release scripts.

Git doesn’t quite have an equivalent

The main svn server I’m working on has finally upgraded to svn 1.5 - so easier merging is now possible - hooray.

But we’ve been seeing merges that should only affect one file resulting in property changes on lots of files/directories. This isn’t especially harmful - but it is annoying and makes reviewing the merge harder because of the extra noise.

It turns out that this extra mergeinfo is likely because of earlier merges on subtrees http://blogs.collab.net/subversion/2009/11/where-did-that-mergeinfo-come-from/

It is possible to remove the subtree mergeinfo via this command run from the root of the branch

You’ll need to have git and git-svn installed.

The code samples are run in bash on Linux.

Reading Greg’s post on security upgrades and a few mentions of patches in the following discussion got me thinking about upgrade methods.

The standard Drupal method is to delete existing files and unpack a tarball to replace the old version - I find this method unappealing because: I keep my code in subversion so don’t want to delete the .svn subdirectories, and sometimes I have patches applied that I don’t want to loose.

I’ve long been puzzled by the official advice on upgrading Drupal

It basically says you should delete everything, unpack a new Drupal version, and replace your customisations.

I like to use version control to manage my site.

I just started on a project that was using trac and subversion but they weren’t integrated. I love the cross referncing trac provides. It can really help explain changesets and show how an issue was resolved.

The steps to add subversion to trac are

I’ve been using version control for a long time, but I haven’t used CVS much since the first day I tried Subversion.

(Git seems great but isn’t the same kind of drop-in upgrade that CVS to Subversion was)

Things I forgot

I recently finished work on a project that really suffered from a lack of build tools.

It was a large project, and while many of us were keen on writing tests we weren’t able to get management sign of to spend some time automating the test process. So even though we did some of the work we didn’t get all the benefits.

It was really frustrating to come back to a piece of work that was well covered by unit tests, only to find those tests broken

I’ve been intrigued by git for a while, but as a long time user of svn I’m kinda cautious about moving on.

So today I had some time and used it to read up on the pros and cons, as well as try things out a bit.

It seems to me that git is clearly the better system; but that svn has the advantage of maturity.