Integration of a SVN storage backend.

Ok ther some problems in the current implementation:
-Make sure that you have no pylint errors in your test cases. There are a lot of "line toolong" messages -> DONE
-datafinder.persistence.adapters.svn.metadata.adapter.MetadataSubversionAdapter._mapRawResult raises a SubversionError but datafinder.persistence.adapters.svn.metadata.adapter.MetadataSubversionAdapter.retireve does not handle it (catch it in retrieve and raise a PersistenceError). Add a test case!!!!!!! -> DONE
- datafinder.persistence.adapters.svn.connection_pool.SubversionConnectionPool._createConnection and datafinder.persistence.adapters.svn.factory.FileSystem._getConnection are implementing the same! Why? Just the the connection pool implementation.-> DONE
- In datafinder.persistence.adapters.svn.data.adapter.DataSubversionAdapter.exists if connection = self._connectionPool.acquire() raises an error, the connection used in self._connectionPool.release(connection) doe not exist. Please correct it and add a test case again.-> DONE
- Trying to retrieve SVN_MIME_TYPE causes a KeyError in datafinder.persistence.adapters.svn.util.cpython.CPythonSubversionWrapper.getProperty. The handling of this situation should be improved as the whole property retrieval should not fail.-> DONE
- The differentiation of SVN and WebDAV backend has to be changed (datafinder.persistence.factory.FileSystem.__init__):
  - Values datafinder.persistence.factory.FileSystem._uriSchemeAdapterMap should ALWAYS be lists.
  - In datafinder.persistence.factory.FileSystem._getFactory go through this list, import the factory and check attribute: canHandleLocation -> should be a read-only attribute defined in datafinder.persistence.common.base_factory.BaseFileSystem. The default implementation should return True.
- Implement it for the svn adapter factory -> Just try a connection and return Fals if anything went wrong.-> DONE

- On update or commit you need to handle the case that the working copy is locked -> an automatic "cleanup" should be performed in this case. -> DONE - sychronized the different processes accessing the working copy
- There seems to be no error if the user provided invalid credentials. Is there a timeout?-> DONE
- After updating the properties of a collection, the value of the "Data Type" property was lost.-> DONE
- Add "hasMetadataSupport" implementation (returns always True / see BaseFactory) to datafinder.persistence.adapters.svn.factory.FileSystem-> DONE

There is still a locking issue:
datafinder.persistence.error.PersistenceError: Cannot determine resource type of '/'. Reason: 'Working copy 'c:\dokume~1\..\lokale~1\temp\c8c95657ed895cb707ce00bf7c173555' locked'
-> Triggered by datafinder.persistence.adapters.svn.data.adapter.DataSubversionAdapter.isCollection
If you want to write to a file you get the following error:
Cannot store the data store configuration Reason: 'Unable to write data to '/datastores.xml'. Reason: 'c:\dokume~1\..\lokale~1\temp\7549ec0c880345b2334f7ae0d70399c6\datastores.xml' is not a working copy directory' -> DONE
- Use os.stat() and st_size to find out the file size, see also: datafinder.persistence.adapters.filesystem.metadata.adapter.MetadataFileSystemAdapter.retrieve
- We have to manage the creation date on our own add the property datafinder.persistence.metadata.constants.CREATION_DATETIME with the current date and time when updating the properties. But do this only if it is not already set. -> DONE, Using the modification date of the creation revision

TODO:
- Test handling of complex domain properties -> Moved to separate blueprint (https://blueprints.launchpad.net/datafinder/+spec/domain-properties) -> Refactored the JSON support , domain objects are implemented as well -> DONE
- Check the Jython implementation -> This is DONE in another release
- Test it on SLED10 -> It works basically. Some, bugs have to be fixed.
- Restrict property and item names -> DONE