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 <qazwart_at_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
> qazwart_at_gmail.com
>
Received on 2011-10-06 18:34:31 CEST