"Steven Whatmore" <Stevenw@sigmasoft.ca> wrote on 12/15/2006 06:27:46 AM:
> Good morning,
>
Good evening!
> <<<snip>>>
>
> We have a distributed development team (one in Canada and another in
> India), where each team has the ability to update and commit code to
> our code repository. Subversion includes a number of benefits for
> minimizing the amount of data being sent in / out of the repository
> on commits, however due to the type of connection that our India
> team has (very slow and unreliable) it makes sense to have a
> federated repository setup.
>
> <<<snip>>>
>
> synsync is not a solution for this problem in that synsync creates
> read-only mirrors and would not allow one of the teams to make
> commits to their local repository.
>
I don't know how well this would deal with your unreliable
conenctions, but we use Riverbed Steelhead appliances to increase the
performance of our network connection between Newport Beach and remote
sites (such as Kiev), which (according to second-hand reports) has
provided a very good performance increase.
However, even if that isn't an option, maybe svnsync would be OK.
If you can make sure that the mirror's UUID is the same as the main
repository, the developers in India could check out & work from their
local mirror, and then do an `svn switch --relocate` before committing
changes. In CVS, I would commonly work on a checkout from a read-only
mirror, applying diffs to my read/write working copy for committing
(although I'd have to manually take care of file deletion/creation).
I agree, it's not the best solution (and could easily become very
confusing), but it's a possible stopgap measure. Good luck!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Dec 16 10:23:38 2006