[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: remote site dev: single repository vs mirror repos

From: Ryan Schmidt <subversion-2006d_at_ryandesign.com>
Date: 2006-10-18 22:49:19 CEST

On Oct 18, 2006, at 11:30, Tim Liu ((gangliu)) wrote:

>>> I am investigating subversion repository strategy for remote site
>>> developement. Please share u experience/opinions. very appreciate
>>> it.
>>>
>>> 2 choices:
>>>
>>> 1. One way is to have a single repository. All developers in
>>> different geographic sites will access it via either Apache or
>>> svnserver.
>>> 2. The second way is to have mirror repository in different sites
>>> and syncup (2 ways both read/write) among them.
>>>
>>> Which way is widely used in remote site dev among subversion users?
>>> Assume network bandwidth is not a issue. it is high-speed.
>>>
>>> I can see #1 is easier to manage but performance may be a concern
>>>
>>> #2 maybe look like performance is good.
>>
>> It's very easy: Subversion does not provide option #2, so you must
>> use
>> option #1.
>>
>> If you want to try option #2, look into SVK, which is based on
>> Subversion and should support that.
>>
>> http://svk.bestpractical.com/
>
> Subversion 1.4 has svnsync. Does it support option #2?

No, it does not. svnsync lets you make read-only mirrors of a
repository, not read-write mirrors which seems to be what you want.
svnsync is also not ideal even if you want to be able to conduct read-
only operations on the mirror and then check in to the master.
svnsync is only really appropriate if you want to have read-only
mirrors that will only be accessed by people who will only read,
never write.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 18 22:50:06 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.