Sometimes you need to review what exactly doing an svn up
will do. Fortunately, you can do a couple of things to find out. The
first is use svn status -u to find out what files have
changed:

/etc/puppet/modules# svn stat -u
       *     1338   exim4_mailserver/files/exim_db.pl
       *     1338   dbplc/files/sort-dbfs.pl
       *     1338   dbplc/files
       *     1338   dbplc/manifests/portal.pp
M            1386   tomcat/files/server.xml
Status against revision:   1386

Here we can see that four files were changed since their current
revision of 1338. We can also see that tomcat/files/server.xml is up to
date against the repository, but has local modifications.

This is all well and good, but how do we know what the changes are?
Well, svn diff is our friend here. By comparing the checkout
against the repository, we can see what will be updated.

/etc/puppet/modules# svn diff dbplc/manifests/portal.pp -rBASE:HEAD
Index: dbplc/manifests/portal.pp
===================================================================
--- dbplc/manifests/portal.pp (working copy)
+++ dbplc/manifests/portal.pp (revision 1386)
@@ -22,6 +22,7 @@
       owner => "tomcat55",
       group => "adm",
       mode => 644,
+      require => Package["tomcat5.5"],
    }

    apache::config { "portal":

When you’re happy, you can run svn up as normal. I’ve just
used this process to sanity check our Puppet config before updating, as
it hasn’t been updated for a few days.

Was attempting to merge a branch in one of my projects and upon
committing the merge, I kept getting this error:

mojo-jojo david% svn commit -m "merge in the maven branch"
Sending        trunk
Sending        trunk/.classpath
Sending        trunk/.project
Adding         trunk/.settings
svn: Commit failed (details follow):
svn: Server sent unexpected return value (502 Bad Gateway) in response
to COPY request for '/svn/eddie/!svn/bc/314/branches/maven/.settings'

A quick search found several other people having the same problem.
Seems it only happens for https repositories using mod_dav_svn.
The solution is to make sure that your virtual host in apache has
explicit SSL config options, even if you are using an SSL config from a
default virtual host. For example, I added the following to my
subversion vhost, which was just copied from my default vhost:

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/catnip.org.uk.crt
SSLCertificateKeyFile /etc/apache2/ssl/catnip.org.uk.key