Subversion is not disributed - try svnsync for a while, most of the pain should go away otherwise check out http://www.wandisco.com/
On Thu, Oct 6, 2011 at 9:22 AM, David Weintraub <qazw...@gmail.com> wrote: > 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? the checkin is "proxied" by the mirror - don't mess up the WC with a relocate 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, that would be WANdisco > 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 >
