Note to self: In order to allow changes to the author of an svn commit, the pre-revprop-change hook of the repository must be changed like this:

Insert the line

if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:author" ]; then exit 0; fi


just below the existing, similar line that allows changing svn:log. Omitting the comments the script will then look like this:

#!/bin/sh
REPOS="$1" REV="$2"
USER="$3" PROPNAME="$4"
ACTION="$5" if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi if [ "$ACTION" = "M" -a "\$PROPNAME" = "svn:author" ]; then exit 0; fi

echo "Changing revision properties other than svn:log is prohibited" >&2
exit 1


The script is located in the hooks subdirectory of the repository.
(Of course the above is for an svn repository located on a Linux server only.)

This change is required for the context menu entry in TortoiseSVN Log Messages window called “Edit Author” to work.

Many open source projects have moved from the former top dog SlashdotSourceForge to GitHub and in the process usually converted from Subversion to git. This also includes quite a few Delphi libraries like project Jedi (JCL/JVCL), SynEdit or Indy.

I am not really comfortable with git, it just feels too complex for most projects and the GUI tools I have tried are clunky compared to TortoiseSVN. I see some advantages, but so far I’m not convinced. So, I have stayed with SVN and used that to access GitHub repositories through their git-svn bridge. This works fine, most of the time, unless you want to rename a file, which apparently is not possible for whatever reason.

Now, contributing to such projects is another challenge. You need to create something called “pull requests“, which basically is a way of creating patches that are centrally managed by GitHub together with a discussion area for them. It took me a while to get my head around the process but I think I got it now. So here are the steps:

1. Get a GitHub account. There is no way around that.
2. Fork the repository of the project to which you want to contribute.
3. Create a branch in that forked repository. You need a separate branch for each pull request you want to create! (That was the main stumbling block for me, I just didn’t realize this. It’s probably documented somewhere but I overlooked it.)
4. Check out that branch.
5. Make your changes in that branch
6. Commit those changes and push them to GitHub
7. On GitHub, create a pull request

There are many sites that give you these steps sometimes with examples on how to do them, but always using git. Here is, how to do it without a git client, but using svn + the aforementioned git-svn bridge.

GitHub shows a url for each repository that can be accessed via git or svn. It looks like this:

https://github.com/[account]/[project].git


Remember that this url contains the the whole repository, so in order to check out only the trunk (master branch) or a branch, you need to add /trunk or /branches/[branchname] to it.

Creating a branch can be done either with svn in the usual way or with the web UI on GitHub. I prefer the latter which is done by typing a non-existing name for a branch and pressing enter.

For the following steps lets assume we created a branch called “pullrequesttest”.

Using the svn client of your choice (mine is TortoiseSVN), check out the sources of the branch we just created. The url would be:

https://github.com/[account]/[project].git/branches/pullrequesttest


Just make your changes and commit them the usual way. Subversion does not distinguish between a commit and a push to the server as git does.

The branch now contains the changes you want to submit to the project.

On GitHub, select that branch and you will see a message about your changes an a button “Compare & pull request”.

Click that button, add a comment and submit the pull request. It should show up on the original project’s page. Somebody with the rights to it can now approve and merge these changes. They can also be discussed there. Maybe some further improvements are necessary to get them accepted. For that you simply make changes to the code you have checked out and commit them to the same branch. They will automatically become part of the pull request (Remember that I said you need a separate branch for each pull request? That’s why.).

Now suppose there are other, unrelated changes you would like to submit? Start with creating a new branch, based on master, check out the code, make the changes commit them and create a new pull request for the new branch.

Just remember to never make any changes to the trunk (=master branch). That one is meant to have the same content as the original repository and the base for each branch to be used for a pull request.

I’m sure this description is more complicated that it needs to be. My main idea in writing this article is to get a starting point for creating pull requests without having to use git. If you can think of improvements, please discuss them in Delphi Praxis. Note that this is not meant to become a discussion about the merits of git vs. Subversion. We don’t need another one of these.

Since I keep forgetting what the tool is called and how to use it:

svnrdump is a tool that can dump a remote svn repostory to a text file and also load that text file into a different remote svn repository. It comes with the TortoiseSVN installation (but is really part of the standard Subversion tool set).

My use case is migrating projects from SourceForge to OSDN. On the OSDN side the option “Allow to modify revision properties for project members” must be enabled which is available on the Subversion -> Admin page. It really takes a few minutes for that option to become active.

To dump a repository:

svnrdump dump https://source.site/some/repository/ > somerepository.dump


svnrdump load https://dest.site/some/repository < somerepository.dump


Of course, since svnrdump writes to stdout and reads from stdin, it should be possible to do both in one go:

svnrdump dump https://source.site/some/repository/ | svnrdump load https://dest.site/some/repository


But I have never tried it. I prefer getting a dump file first, just in case anything goes wrong.

Today I moved bdsproj2cfg and dof2cfg.

Recently SourceForge’s service has declined to a point where it gets really annoying. Basically every time I tried to commit a change to the svn repository of one of my projects, I run into timeouts and other errors. I want to spend my time working on my projects, not convincing their infrastructure to accept my changes.

So I went looking for alternatives and discovered that basically every hosting service nowadays supports git, some add Mercurial and only very few also offer Subversion. Some claim to offer Subversion access to git repositories but whenever I actually tried that, it turned out that it either didn’t work at all or had limitations. Usually the limitation was that svn:external tags were not supported.

OK, this blog post was supposed to be about getting a dump of a remote svn repository, not about hosting services and their limitations…

The usual advice you find, when you google for “svn dump repository” is to use svnadmin. Unfortunately it turns out that svnadmin only works for local repositories so it is not suitable for dumping a repository on SourceForge. There are a few tools that claim to sync repositories but none of them worked for me. Eventually I found a reference to svnrdump, which is included in TortoisSVN and is exactly what I was looking for:

svnrdump dump http://svn.code.sf.net/p/dzlib/code > dzlib.svndump


creates a dump of the repository in the same format as svnadmin does. In theory it can also load that dump into a remote repository, but that requires that the target repository has been prepared for that operation.

Unfortunately, even that operation timed out just now why trying to download revision 162 (of 744), so I’m back to square one.

Edit: I eventually succeeded with the above command. But, as Ondrej Kelle pointed out in his comment on my Google+ post, for SourceForge there is a simpler and more robust way: Create a local copy of the repository.

rsync -a -v svn.code.sf.net::p/dzlib/code/ .


It’s even documented in the SourceForge support documentation (I only found it after I knew of this option). It requires the rsync tool, which is not available under Windows by default, but hey, are there any developers who don’t have access to a Linux computer or VM?

Once you have got that local copy, you can simply use svnadmin to create a dump from it:

svnadmin dump --incremental --deltas path\to\repository > repository.dump


I added the options –incremental and –deltas after initially loading the dump into a fresh repository failed when it encountered the first binary file. With these options, the problem did not occur.

svnadmin load --file repository.dump path\to\new\repository


Note: The following failed for me under Windows 8.1:

type repository.dump | svnadmin load path\to\new\repository


The latest 1.9.x versions of TortoiseSVN no longer support Windows XP (1.8.12 was the last one that did). Since some of the computers I work with are stuck with XP there isn’t much sense in having it check for updates automatically.

Older versions of TortoiseSVN used to have a check box on the settings “General” page, but that apparently was removed later. Now, it is on the “Advanced” page and called “VersionCheck”. Setting it to “false” disables the check.