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 qazw...@gmail.com
