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