Changelists in Subversion

I recently had a discussion on how to deal with configuration-settings, which might be different for every developer, in regard to subversion. The main question was: “should these files also be commited to the repository?”

The answer is plain and simple – yes! But it doesn’t make sense to check-in my settings for all other developers, and it even makes less sense that every developer is updating his settings every time he commits and thus overwriting the settings from the previous check-in.

Better: a standard-configuration file is being checked into the repository. This file could contain some placeholders, which must be individually updated. Every developer get’s this standard file on initial checkout, but all further updates to this file are being ignored by subversion.

This behavior could be achieved “manually” in such a way, that on check-in you just have to make sure, that you don’t commit the configuration file to the repository.


This is obviously not really good. Most likely this will fail at some point in time and the individuall settings of a developer will get committed.

So we need a more sophisticated way to ignore certain files on commit. So there is the ignore-option of subversion, but that would also prevent us from initially checking in the standard-configuration. And maybe I would actually make a modification the the standard-configuration and update the file in the repository and make sure that every developrsconfiguration is being overwritten.

To achieve this subversion (or at least TortoiseSVN) offers a feature called change-list. To edit the change-list of a project you must open up the context-menu and “check for modifications”. In the context-menu of the shown files these can be assigned to a change-list. There is always on change-list already existend – “ignore-on-commit”.


An alternative is to start a commit and of all the file to commit these can also via the context-menu be assigned to a change-list.

After the configuration file has been assigned to the “ignore-on-commit” changelist, all updates to theses files will not be automatically commit (as the name might already imply).


If the changes should however be commit, this can be done by simply checking the file in the commit dialog.

Delete Subversion revision

OK, it had to happen sooner or later … some bone-head delete the trunk folder and committed this to the central repository!! Of course this happend 10 minutes before the final build of the first public test-release …

OK, so what to do now? First of all, check out a previous revision. OK, did that. So now check everything looks fine, everything builds just fine … OK!

So how to commit that to the repository? The repository know I checked out revision 125, but the latest revision is 126. So what next?

First make a backup of the repository (well, it’s kinda broken, but you never now what could happen next!!). Then dump everything up to revision 125:

svnadmin dump -r1:125 myrepo > my.dump

then create a new repository and load the dump:

svnadmin create myrepo
svnadmin load myrepo < my.dump

This way you’ll end up with a nice and clean repository, which is up-to-date with revision 125 … and the bogus revision 126 is gone!!

This really made my day!!