My setup was this: I have my home desktop computer that runs Windows XP, and the repositories were stored and managed using VisualSVN, a great tool to manage SVN repositories, if you’re running Windows. The applications were deployed on my Windows machine (for developing purposes) and on the hosting server (live, production deployment) that runs Linux. And here’s what I’ve done…

On the source, Windows machine

I’ve stopped the SVN service, so no svn updates/commits would be initiated. I’ve opened up a console and ran the following command:
svnadmin dump d:\Repositories\repo_a > repo_a.dump

Then I’ve packed the repo_a.dump file because it’s almost plaintext and copied the archive to the destination server.

On the destination, Linux machine

I’ve unpacked the dump file and then:
svnadmin create repo_a
svnadmin load repo_a < repo_a.dump

After that, I needed to chown -R www-data:www-data ./* to make the files belong to apache, and then add the authentication back.

This is just about it for the relocation of the repositories. But we need to do one more thing: alter all the checkouts to point to the new repositories. This is done in a way on a Windows machine, and a bit different on a linux machine.

Checked out repositories fixing

To make all the deployed checkouts point to the new server, you need to edit every file called "entries" that is located in every ".svn" folder of a checked out repository.

To do that, on Windows you can use grepWin, a lovely tool that does all the work:

There you have it. On linux, you'll need perl:
find ./ -name "entries"|xargs perl -w -i -p -e "s/svn\.example\.com/new\.server\.com/g"

This command replaces all the occurences of "svn.example.com" with "new.server.com" in all the files named "entries" in the current folder and below. Replace for your own needs.

Until now, when running svn update on a linux commandline that included a conflicted file, you would get a really messed up set of file regarding the conflict. That is why a HTTP server would have to be stopped while updating, since it would make the website/application unusable.

But now, thanks to Interactive Conflict Resolution, you could do something like the following (described on their site):


$ svn up
U contrib/client-side/svnmerge/svnmerge_test.py
Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
Select: (p) postpone, (df) diff-full, (e) edit,
(s) show all options: s
(p) postpone - mark the conflict to be resolved later
(df) diff-full - show all changes made to merged file
(e) edit - change merged file in an editor
(r) resolved - accept merged version of file
(mf) mine-full - accept my version of entire file (ignore their changes)
(tf) theirs-full - accept their version of entire file (lose my changes)
(l) launch - launch external tool to resolve conflict
(s) show all - show this list

Select: (p) postpone, (df) diff-full, (e) edit,
(s) show all options: tf
G contrib/client-side/svnmerge/svnmerge.py
Updated to revision 25685.
$

And finally, Merge tracking means Subversion keeps track of what changes have been merged where. This reduces the overhead involved in maintaining branches, and gives users a way to inquire what changes are merged — or are available to be merged — on different lines of development.

Also, VisualSVN version 1.5 has been released to go with the latest features of Subversion.