Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 531ED773F for ; Thu, 6 Oct 2011 16:23:01 +0000 (UTC) Received: (qmail 66822 invoked by uid 500); 6 Oct 2011 16:23:00 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 66797 invoked by uid 500); 6 Oct 2011 16:23:00 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 66790 invoked by uid 99); 6 Oct 2011 16:23:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2011 16:23:00 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of qazwart@gmail.com designates 74.125.82.171 as permitted sender) Received: from [74.125.82.171] (HELO mail-wy0-f171.google.com) (74.125.82.171) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2011 16:22:54 +0000 Received: by wyh13 with SMTP id 13so4850023wyh.16 for ; Thu, 06 Oct 2011 09:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=YGaAqbwYNx73klLy2xTIkdHrXRwpwjFaE14O0cyrftI=; b=SPSasuY5/ttqp/oacs+MkzHmynZl0QTJ6INbwYueTbyo0f2O9BwcKnlfISaW4QicDs OlPNqGuWp9suEqNHjA9ByYKabAXZoWkMjRtszfnu8oD8gFZ+E+v44xp0EZNxUxcjBvbG yihBhcgd4lc05opTljstOJxZbYEW0OVdWAAYk= MIME-Version: 1.0 Received: by 10.216.195.22 with SMTP id o22mr1222417wen.2.1317918153623; Thu, 06 Oct 2011 09:22:33 -0700 (PDT) Received: by 10.216.29.202 with HTTP; Thu, 6 Oct 2011 09:22:33 -0700 (PDT) Date: Thu, 6 Oct 2011 12:22:33 -0400 Message-ID: Subject: Subversion and Remote Repository Synchronization From: David Weintraub To: Subversion Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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 . 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@gmail.com