Blog

Merge tracking with Subversion 1.6

Posted on by Matthew Skelton (@matthewskelton)

I am now running Subversion 1.6 for my client’s SVN repositories. I upgraded mainly to take advantage of the Merge tracking introduced in Subversion 1.5, and improved in 1.6. In particular, Subversion now creates its own “mergeinfo” entries, so you no longer have to use the svnmerge.py script. Subversion 1.6 now has better detection of “tree conflicts” – essentially, problems with the local working copy caused by renames, missing files, etc.

I used the new release of VisualSVN Server to install and upgrade SVN in a painless way (see earlier post on VisualSVN Server). The new version installs over the top of the previous one, so back up your SVN repositories first.

An important part of the Subversion philosophy is “don’t break things”. Even though VisualSVN Server 2.0 runs Subversion 1.6, the underlying repository format is not upgraded automatically, meaning that the new merge tracking feature is still not (yet) available. To get this working we simply need to run “svnadmin upgrade PATH”, like this:

> svnadmin upgrade D:\Data\Svn\DevDoctor
Repository lock acquired.
Please wait; upgrading the repository may take some time...

Upgrade completed.

Following a working copy svn update, you can run svn merge. In this case, I used TortoiseSVN:

Here, we were merging from the development branch, so I selected Reintegrate a branch. Once the correct settings have been chosen, you can even “Test merge”, which gives you a report of what would happen if you went ahead with the merge. When the changes are successfully merged, Tortoise shows the results:

As normal, the merge needs to be committed, but the crucial difference after the commit succeeds is that Subversion itself has tracked the merge using the mergeinfo property:

You can see that an svn:mergeinfo property has been set on the folder, showing the branch from which the merges were done, and the revision numbers (here, 400-409).

All this means that merging (both from branches to trunk, and from trunk to branches) is all much less tricky and error-prone than before (with Subversion 1.4). Subversion 1.6 is also noticeably quicker than 1.4 for all operations so far.

Further reading: http://scm.jadeferret.com/subversion-16-new-features-explained/

PayPal "cart upload" – much smoother than "Add to cart"

Posted on by Matthew Skelton (@matthewskelton)

We have just finished some custom PayPal integration for Eaton Square Concerts (ESC). On the ESC booking page, you can now select all the tickets you want before heading to PayPal, thanks to the PayPal “cart upload” feature. Previously, the site was using the single-item “Add to cart” which is a bit clunky, and means the user heads back and forth between the ESC site and PayPal.

We handle the form submission on the ESC site, work out what the user want to buy, read their response to the optional questions, and then send the form off to PayPal. The intermediate step is needed because PayPal refuses to accept a zero-count for items, forcing us to check the item count before POSTing to PayPal.

Formatting an external drive with FAT32 under Windows

Posted on by Matthew Skelton (@matthewskelton)

The GUI in Windows XP later OS’s allows only NTFS as the format type for external drives; not too handy when you want to transfer files both ways between a PC and a Mac, as Macs can only read (not write) NTFS partitions.

However, you can drop into a command prompt to force formatting using FAT32:

format /FS:FAT32 X:

This is good for drives up to 32GB, which is still a bit small. For drives of up to 8TB, you’ll need a partition tool such as SwissKnife, PartitionMagic or Acronis Disk Director.

Original info from here: http://www.online-tech-tips.com/computer-tips/formatting-external-hard-drive-to-fat-32/

Loading spinner GIFs – loadinfo.net

Posted on by Matthew Skelton (@matthewskelton)

There is a great collection of “loading…” spinner GIF images at http://www.loadinfo.net/ such as this:

Spinner GIF from loadinfo.net

Crucially, you can also generate your own spinners, with settings for back- and foreground colours and transparency.

How to encrypt passwords in the Tomcat server.xml file

Posted on by Matthew Skelton (@matthewskelton)

By default, Tomcat stores passwords in server.xml in clear text, which can lead to obvious security lapses.

The easiest way to mitigate against user account compromise is to use a password digest (SHA, MD2 or MD5 are supported).

With $CATALINA_HOME/lib/catalina.jar and $CATALINA_HOME/bin/tomcat-juli.jar on your class path, just use the following to generate the digested passwords:

java org.apache.catalina.realm.RealmBase \
   -a {algorithm} {cleartext-password}

The digest technique works by having the incoming clear text password (as entered by the user) digested, and the results compared to the stored digested password. If the Two digests match, the password entered by the user must be correct, and the authenticate() method of the Realm succeeds.