For various reasons - We have "the-one" windows computer that has access to a svn repo. This svn repo is located on a separate svn server machine and this server/svn is not accessible to any other computer, from either the intranet or internet.
Said "the-one" computer has tortoise SVN and pulls stuff from the repo via 'svn checkout'.
We also have linux, windows/cygwin and macos boxes on the same local network. Unfortunately none of them can mount the "the-one" windows computer as a shared drive, although they all individually have rsync installed on them.
We would like to be able to share/serve this 'the-one' tortoise SVN folder as a master SVN repo to people working on these other computers.
Eventually, we will commit these changes back from other-people => 'the-one' => svn repo weekly.
Is this recursive serving of SVN checked out files possible ?
What you ask for is not possible with Subversion.
Subversion is a centralized version control system. Centralized means there's one repository to which clients connect. The repository consists mainly of a database which contains all the content and the history of the changes. These are stored in a binary, optimized format.
In contrast to that, any client has a working copy which contains (part of) the content, where the repository can be found and the last synchronized state of the local content as it would be found in the repository. Working copies usually contain textual data like source code and configuration files.
Long story short: repositories and working copies are not the same and you cannot use them interchangeably.
In your question, you do not explain where the repository resides. Is it also on "the-one" PC? If so, it should probably run a Subversion server to which clients can connect. It is also possible to copy an entire Subversion repository, e.g. through the svnadmin commands. This allows you to set up a repository in a more convenient location.
If you really want to share a working copy between several contributors, note that nothing will prevent them from overwriting each other's changes. This defeats the purpose of using a VCS. You would need to put another means of version control in place.
It may be tempting to consider git svn which creates a Git repository connected to a Subversion repository as an intermediary. Note however its documented caveats.
As for the rsync approach, that's essentially a very basic implementation of your own little VCS. I would not recommend it. Anyway, it might work until you run into trouble because ...
In any case, I'd advise to rsync only the content, not the metadata. That means ignoring the .svn directory in the working copy. We would not want to rewind the working copy to an earlier stage because somebody rsync'd last month's .svn dir back (which should be fixed with an svn update but better to prevent these things in the first place).
FWIW, I've used unison (which is essentially a two-way rsync) for some rudimentary backup tasks. You might find it useful. I would still recommend to use a real VCS over a homegrown solution.