One folder in multiple SVNs

Question

So I have this awkward "one girl two cups" situation where we use SVN to write research papers. We have a common database with bibliographic citations (us sciencemen call it references) which is kept in a separate folder and is used by all the papers we write. The structure looks like this:

[repository on server A]
    PaperA
        paperA.tex % uses "../references/refs.bib"
    PaperB
        paperB.tex % uses "../references/refs.bib"
    PaperC
        paperC.tex % uses "../references/refs.bib"
    References
        refs.bib

So far so good.

Now I need to cooperate with colleagues from a different university which do not have access to this SVN (I can't have guest accounts made for those people because of some ridiculous "not our government employee / hardware usage" rules). So what I need to do is to start a public repository which they can access as well:

[repository on server B]
    CollaborativePaper
        paper.tex % will use "../references/refs.bib"
    references
        refs.bib % this now exists in two different repos

I was wondering if there is a way to keep the references folder somehow synchronized between both repos? I guess what I'd do in Linux would be a symlink to the same files / directory which would be committed to both repos so every time I check out changes from one, I could commit it to the other without actually copying any files manually and merging would be taken care of. But I'm in Windows so no such luck there.

I was looking into svn:external items, which would be great in this situation, except that the colleagues from a different university do not have access to both repos and it is thus useless.

I was also looking into vendor branches but those are basically manual copies of the files with a fancy name and do not synchronize both repos for me (or at least that's my understanding).

I was also looking into a nested working copy, which works for me personally, but the nested files (refs.bib) are never committed into the collaborative repo, so the colleagues from a different uni won't be able to use it / make changes to it.

Is there any way to have a single physical folder exist in two SVN repositories running on different servers, in Windows?

EDIT: While this is similar to Same working copy of the code with 2 SVN servers (which is itself answered by another SO questions) there are some differences. The first question How to synchronize two Subversion repositories? assumes that the users have credentials to both servers. This is not true here. The second one Can I have one project in two SVN repositories? assumes no collaboration (the OP just wants his files safe over the weekend until he comes to the office at monday to commit). The third SVN: one working copy, two repositories? is the mix of the two. None of answers to these questions offer workable solutions for me.

Answer 1

1. With DVCSes (any) instead of SVN you'll have less headaches in such "distributed" teams (I'll recommend Mercurial with subrepos, not Git with anything)
2. Yes, externals is The Right Answer, just in slightly trickier way:
   • On external host, reachable from both universities, repository for storing References folder have to be created
   • Your local References have to be moved to REMOTE (load|dump), physical folder have to be removed and replaced by externals definition (two separate commits suggested)
   • Foreign colleagues also add externals References to their own repo (or use the same infrastructure with base tree outside References?)

At the lower level:

• yes, local repository will have in it only some additional metadata "this node have to be obtained from HERE"
• for client's Working Copy of local repository externals, defined in local repo, will produce nested Working Copy, linked to remote repo (you can see it on appearing additional .svn folder in the root of checkouted externals). It is normal (in common sense) Working Copy, which meets all standard conditions and requirements for the WCes (all needed actions just replied for both WCes - wrapper and nested), and yes: if repository isn't open, you have to provide from client-side all required credentials, but... unique user for each client is obvious overkill: from the functional side it is enough to have 2 user - "Reader" and "Full Access" (for committer, in order do not change credentials on the fly in the process)