You could write an SVN-based cache loader - basically a loader that uses SVN to read contents, generate the cache objects.
You would probably configure this not to use an eviction policy though, since you don't want objects to expire, rather to trigger an eviction when SVN detects a change. So you would have to write your own code to listen for changes in SVN, and when a key has changed, manually evict the key (or all affected keys) from the cache using the cache.evict() API.
Once the keys are evicted, the next call that comes in for this key will trigger a load from the CacheLoader, which could then build the object on demand.
I have the code written though it's completely separate from jboss cache. As it doesn't make much sense to write a separate cache, I want to intergrate it.
However I think I cannot use CacheLoaders too, because I don't want any calls to trigger loads from the CacheLoader --- the keys have to be updated in the background. So basically, a thread watches for changes in the backing store (SVN, filesystem, etc), and when a change is detected, updates the current value with a new one. The user never has to wait for the value to be read from the store, parsed and so on.
(The thread-approach is more or less how it is now, I was just wondering if it could be done with cache loaders/ eviction policies, but I suppose not)
Then I suppose just use the cache as a cache, don't use eviction policies or cache loaders. :-)
That's what I'll do. Thanks for the answers :)