SVN Rolling Back A Commit To A File

I needed to roll back an SVN commit done recently to an init script for one of our daemons, it’s a very easy process!

First we need to see what the latest revision number of the file that we want to roll back is


Chill:files idimmu$ svn info slee
Path: slee
Name: slee
URL: http://svn.idimmu.net/msu/trunk/puppet/modules/jnetxslee/files/slee
Repository Root: http://svn.idimmu.net/msu
Repository UUID: 573313b0-15b8-499c-acf0-a5a26a3c7166
Revision: 1517
Node Kind: file
Schedule: normal
Last Changed Author: idimmu
Last Changed Rev: 1256
Last Changed Date: 2010-08-12 10:51:15 +0100 (Thu, 12 Aug 2010)
Text Last Updated: 2010-08-12 10:50:57 +0100 (Thu, 12 Aug 2010)
Checksum: 8940fdf3ed6ee8281b94f55c2fe7880a

As you can see the Last Changed Rev is 1256, this is the important number 😀

Now we want to run a diff of the revision prior to the commit, 1255, and the current file, 1256


Chill:files idimmu$ svn diff -r 1255:1256 slee
Index: slee
===================================================================
--- slee (revision 1255)
+++ slee (revision 1256)
@@ -40,12 +40,12 @@

case "$1" in
start)
- if kill -0 `cat $SLEEPID` > /dev/null 2>&1; then
+ if kill -0 `cat $SLEEPID` 2> /dev/null ; then
echo "SLEE is already running"
exit
else
rm -rf $SLEE_HOME/slee/tmp/*
- if $SSD --start -b -c $RUNAS -d $SLEE_BIN -x $SLEE;then
+ if $SSD --start --oknodo -b -c $RUNAS -d $SLEE_BIN -x $SLEE;then
echo "Starting SLEE"
else
echo "Cannot start SLEE"
@@ -53,8 +53,9 @@
fi
;;
stop)
- if $SSD --stop --quiet --retry=TERM/30/KILL/5 --pidfile $SLEEPID;then
- echo "Stopping SLEE"
+ echo "Stopping SLEE"
+ if $SLEE_HOME/slee/bin/node.sh -h $SLEE_HOME -m com.jnetx.slee.management.hostagent.Shutdown 1 >/dev/null;then
+ echo "Stopped SLEE"
else
echo "Problem stopping SLEE"
fi

The diff shows the changes so you can confirm that you’re on the right track!

We then just issue a merge to revert the file, and then a commit!


Chill:files idimmu$ svn merge -r 1256:1255 slee
--- Reverse-merging r1256 into 'slee':
U slee
Chill:files idimmu$ svn commit -m "rolling back the slee init script"
Sending files/slee
Transmitting file data .
Committed revision 1519.

and we’re all done 😀

Version Control with Subversion

For more SVN advice, I recommend Version Control with Subversion by O’Reilly. It contains everything you need to know when using or managing SVN repositories.

svn: Aborting commit: remains in conflict

I got this annoying SVN error today, that I hadn’t come across before. Even after resolving the conflict in the file, highlighted by lots of <<<<<<<, I still couldn’t get my commit to work!

idimmu@boosh:~/work/systems/trunk/dns$ svn ci idimmu.net -m “new funky domain”
svn: Commit failed (details follow):
svn: Aborting commit: ‘/home/rus/work/systems/trunk/dns/idimmu.net’ remains in conflict

After some reading it was easy to resolve!

idimmu@boosh:~/work/systems/trunk/dns$ svn resolved idimmu.net

Resolved conflicted state of ‘idimmu.net’

rus@boosh:~/work/systems/trunk/dns$ svn ci idimmu.net -m “new funky domain”
Sending idimmu.net
Transmitting file data .
Committed revision 14281.

A lesson in regular svn updateing I guess 🙂

Version Control with Subversion

For more SVN advice, I recommend Version Control with Subversion by O’Reilly. It contains everything you need to know when using or managing SVN repositories.

SVN COPY 502 Bad Gateway error

Our developers were experiencing a weird problem recently with our SVN installation where they couldn’t copy any files in SVN, they would always get the following error


svn: COPY of /project/!svn/bc/5121/trunk/path/file.gif: 502 Bad Gateway (https://svn)

A quick fix of course would have been to just create a new file and copy the contents but this wouldn’t have kept the file history. A quick google lead to this page and a solution!

Our specific problem was we had tried to be lean and set up a default https config that all our SSL sites used which specified the SSL parameters in, but we hadn’t explicitly enabled SSL in the svn vhost, so although SSL was working fine, Apache and mod_ssl actually thought the request was coming through on port 80, and thus http, instead of port 443, https, so the request was being translated to technically copy a file from one svn repository to a completely different one.

The solution was to put the SSL engine and cerficiate options back in to the svn vhost so Apache would pick up that the connect was indeed https and not http!

Version Control with Subversion

For more SVN advice, I recommend Version Control with Subversion by O’Reilly. It contains everything you need to know when using or managing SVN repositories.