Subversion and Remote Repository Synchronization

Let's say I have a team in the U.S. where my Subversion repository is
kept, and I have a remote team in India. The remote team in India is
complaining about the length of time for checkouts and commits. Is
there a solution to this particular issue in Subversion?

I could create a local Svnsync repository, but that's read-only. Is it
possible for the Indian users to checkout from the SvnSync repository,
then do a relocate to the U.S. main repository, and then check in
their changes? Would this be any faster than directly checking out
from the U.S. repository?

What about using "svngit"? We could have an automated process that
pulls data from the Subversion repository in the U.S. and creates a
local Git repository in India using "svngit'. This could be done when
there's no one in the Indian office. Developers could then checkout
and commit their changes to their local Git repository. In the middle
of the night, the Git repository could then push its changes to
Subversion using "gitsvn" Is this a possibility?

I know other revision control systems have a variety of methods in
handling this issue:

* Git, of course, can easily create a local Indian copy of the
repository, and everyone there can checkout and commit to that local
repository. Changes in the local Indian Git repository can then be
pushed to the U.S. main Git repository.

* Perforce can use repository proxies
<http://www.perforce.com/customers/white_papers/distributed_software_development_perforce>.
The proxies will deliver local copies of a requested checkout if it
exists, or fetch the copy from the remote server when necessary. There
is no synchronization issues, but later checkouts are fairly fast. In
fact, many sites have a nightly process that pre-fetches the data from
the remote repository to the proxy since the first request for a
particular version of a file will take a long time.

* ClearCase has the most interesting (and complex) solution. ClearCase
has something called MultiSite. With MultiSite you create a local copy
of the remote repository. This is similar to SVNSync. However, what
MultiSite does is only give one site read-write permission on a per
branch basis. Other sites will be able to see that branch, but it will
be read-only. Instead they'll have their own read-write branch (which
is read-only to everyone else).

For example, I have a site in India and in the U.S. My repository is
in the U.S., with MultiSite, I create a duplicate repository in India.
My U.S. office can read and write to our "trunk" (/main in ClearCase
parlance), but the India office can only read data from the "trunk".
The Indian office creates a branch based upon the trunk called
"india". The Indian office can read and write to that branch. The
U.S. office only has read capabilities on this branch.

This will allow the U.S. office to merge the changes from the "india"
branch to "trunk" and allow the Indian office to synchronize the U.S.
changes from "trunk" to the "india" branch.

I was thinking of implementing some sort of MultiSite in Subversion,
but although the branches would "match", there would be an issue with
revision numbering. For example, in ClearCase, both the Indian office
and the U.S. office would be talking about the same version when they
talk about revision #6 of a particular file on the trunk or version
#24 of a particular file on the Indian branch. This is because each
file and each branch has their own numbering scheme. However, in
Subversion, since the whole repository is revisioned, what would be
revision 6 of /module/trunk/build.xml in the U.S. could be revision 15
in India.

Any ideas?

-- 
David Weintraub
qazwart_at_gmail.com