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

There is

git archive

Which creates a tarball rather than a set of files, and while you can export a subset of the repository you still get the full path in the tarball.

and

git checkout-index

Which creates a set of files (these can be locate outside the working copy) but requires a local repository.

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...

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

The code samples are run in bash on Linux.

Initial Import

The import process can be slow if you have a lot of history to import as git-svn has to pull in every single revision individally. I've found it worthwhile creating a tiny svn repository to practice with as imports are quick and mistakes cheap.

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.

My current project uses the pressflow fork of Drupal, I downloaded the current and new versions of this, added them to my repository and then upgrading my working copy is as easy as

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.

Git in itself seems to have grown up, it's just that the supporting infrastructure and developer experience is still limited.

When you want to see what svn update is about to do you may try

svn update --dry-run

But this doesn't work.

You can get the results you need by running

svn status -u