It is possible but not necessarily simple: the problem you are trying to solve is dangerously close to setting up a distributed development environment which is not exactly what SVN is designed for.
The SVN-mirror way
You can use svn mirror
as explained in the SVN book documentation to create a read-only mirror of your master repository. Your developers each interact with the mirror closest to them. However users of the slave repository will have to use
svn switch --relocate master_url
before they can commit and they will have to remember to relocate back on the slave once they are done. This could be automated using a wrapper script around the repository modifying commands on SVN if you use the command line client. Keep in mind that the relocate operation while fast adds a bit of overhead. (And be careful to duplicate the repository uuid - see the SVN documentation.)
[Edit - Checking the TortoiseSVN documentation it seems that you can have TortoiseSVN execute hook scripts client side. You may be able to create a pre/post commit script at this point. Either that or try to see if you can use the TortoiseSVN automation interface to do it].
The SVK way
svk is a set of Perl scripts which emulate a distributed mirroring service over SVN. You can set it up so that the local branch (the mirror) is shared by multiple developers. Then basic usage for the developers will be completely transparent. You will have to use the svk client for cherry picking, merging and starmerging. It is doable if you can get your head around the distributed concepts.
The git-svn way
While I never used that myself, you could also have distant developers use git locally and use the git-svn gateway for synchronization.
Final words
It all depends on your development environment and the level of integration you require. Depending on your IDE (and if you can change SCM) you might want to have a look at other fully distributed SCMs (think Mercurial/Bazaar/Git/...) which support distributed development out of the box.