svn tiene un esquema de cliente servidor.
Todo lo que descargues lo haces desde el servidor y lo que commitees va a ir a ess servidor.
En git te descargas todo el repositorio y su historia, lo que quiere decir que en tu maquina tienes todo lo necesario para ser un “servidor”
Esto permite que lo que bajes de un lado lo puedas replicar o subir a otro lado.
Obvio que no se sincronizan todos, pero como todos guardan la historia tiene instrucciones para hacer ese tipo de comparaciones o mergeos entre distintas ramas de distintos repositorios que tenian un origen comun.
Si ves en github vas a ver muchos repositorios que dicen ser fork de otro. Eso quiere decir que en un punto de la historia se replicó el repositorio y ess comienza a ser base de otro conjunto de elementos.
Otra cosa que puedes hacer es tener tu cliente, y asociarlo a n repositorios, por ejemplo uno de desarrollo , uno de testing y uno de produccion. Entonces lo que haces en el dia a dia lo subes al repositorio de desarrollo,
Las versiones que seran pasadas a testing las subes ademas al repositorio de testing. y cuando lanzas una version nueva la subes al repositorio de produccion.
Si bien es cierto que esto lo podrias hacer en un unico repositorio e identificar los branches, o los releases especificos, tambien te da mucha mas flexibilidad para configurar la seguridad, en que servidor esta instalado cada reposiorio o la confiuguracion de red y accesos que quieras.
En svn siempre lo que bajaste , esta asociado solo al servidor de donde lo bajaste, quiere decir que naturalmente tus cambios cuando commitees van a ir a ese servidor. Si quieres mandarlo a otro servidor tendrias que hacer una copia inconexa con el original y mandarlo a otro servidor, pero no lo haces naturalmente con instrucciones o comandos que el propio svn te provee