Istace Emmanuel wrote:
Ok, but that's not what i we at work. The local svn will be a "working copy"
of the external svn. In fact, no user have to use the external svn if
there's a local svn. The goal of this is the limit the access to the WAN. If
the external svn is sync twice per day, we can limit these access and
decrease the commit time for internal user (we have no external user).
If you have no external users, why not put the main repository on the LAN
instead of a copy? If you need an offsite copy for backup, do the svnsync
periodically to the WAN copy where you don't have to worry about any other commits.
A LAN
commit is faster than a WAN commit (the bandwith is lower for wan) And we
can have a better security, we have no control on what's do on the WAN with
our data and many commit from LAN to WAN are "point of access to private
data" (SSL or not, ssl is not a good security, you can spoof him easily).
Should I be worried about banking transactions or credit card orders?
We
can limit this risk by limitting the data who are sent.
You could use any kind of VPN you want with the remote site. Use an IPSEC
tunnel between hosts if you don't trust SSL. Or OpenVPN with blowfish.
--
Les Mikesell
lesmikes...@gmail.com
