We looked at storing the configurarion in a database and didn't like it... and yes, I include relational and no-sql databases in that. The rather obvious solution is to use text files for your configuration.
Text files are easy to create, edit, save, load and transfer (be it property files, XML, JSON or this or that DSL, a scala DSL, whathaveyou). They are easy to check into a version management system, track version of and tag, not to mention branch off. Extracting patches and applying them is also easy (the standard diff command on unix or custom diffs for say logical XML documents).
So, now you have a mechanism to promote changes from the development (DEV) to testing (TEST) to the production (PROD) environment... well, not so fast: while it can scale better, it's not that much better than the database, as you still don't know what real differences are there? What is the current 'patch level'? Did anyone modify some files there or not?
Git is a natively distributed version control system. The distributed part is extremely interesting for the purposes of managing configuration.
You see, if done properly, each environment is a 'clone' of the original, or CENTRAL repository. It is in itself, a full repository, having all the tags and file history in common with the original.
Git has utilities to tag and push patches and changes from repository to repository. It allows you to log into any remote environment and extract a diff, see if there are any changes and what patch level you are at. You can either 'push' changes from your DEV environment to TEST or have your client see available patches on a 'public' repository and 'pull' them. This does not mean you loose security, on the contrary - git is very secure, using SSL and user authentication.
You have complete confidence that your support environment is a replica of a given production environment at a given time and so on.
Git is also easy to embed, either as an OS tool or a library inside your project (JAR file), so next time you're looking at a system of medium or higher complexity or which is meant to have distributed configuration management issues, do consider GIT.
Since it's easy to embed, you can go even further and have your configuration tool (GUI) commit the local configuration changes into the local GIT clone and then you have full auditing and tracking as well as the ability to easily rollback that stupid mistake you did this morning in one of 100 files :)