(1) use “svn co” to install from their svn, make sure everything works as much as possible without making any file changes
(2) use “hg init” to snapshot the directory structure (or use any other distributed scm, I happen to like hg)
(3) make your file changes
(4) “hg ci” for another snapshot

At this point, the changes in (3) will be seen as modified files in svn. But you have an hg snapsot in (4). I note that the use of hg is simply to help you track what changes you’ve made. (You could have just left the changes as a bunch of modified files when doing “svn st”.)

When I have to upgrade wordpress, say because of a security problem (that feels like every other day), I do an “svn up” while praying that there will be no conflicts. 90% of the days it seems to be so and I am happy. Then I “hg ci” to snapshot.

You have to choose if you track the .svn directories in hg or not. The advantage is if you roll back using hg, your .svn will be accurate. The disadvantage is diskspace, which is cheap anyway for this amount of code.

The most important benefit is, however, when you get hacked, you know exactly what the hacked changes are. Indeed, I have a job that do an “hg st” on a regular basis and notify me if there are file changes. Here hg comes to rescue to get rid of the hacked changes quickly. I have collected a whole bunch of “tools” and “images” since deploying this.

Thanks