cómo colaborar código fuente en varias ubicaciones

Question

Tenemos una imagen de VMWare que ejecuta una instancia gforge en nuestra red local. Nos gustaría que algunas personas externas formen parte del proceso de desarrollo. Nos gustaría mantener este repositorio como el repositorio maestro SVN. Qué tipo de opciones están disponibles para compartir el código con los recursos externos y fusionarlo nuevamente en nuestro repositorio local.

Otras opciones podrían ser albergar esto completamente fuera de nuestra red (en algunos de los proveedores de hosting), esto no es aceptable, ya que permite a los empleados acceder al código fuera de nuestra red.

Estoy buscando sugerencias para resolver esto.

Answer 1

SVN no es un VCS distribuido. Si desea seguir con SVN, no tendrá otra alternativa real que darles acceso a su servidor local desde el exterior de alguna manera.

Si desea que puedan comprometerse con un repositorio externo separado que no esté físicamente conectado a su servidor interno, y combinar sus cambios en el repositorio central manualmente, tendrá que mirar un VCS distribuido como Git o Mercurial.

Answer 2

Subversion es un sistema de control de versiones centralizado (frente a distribuido). Está diseñado para permitir la colaboración al realizar operaciones concurrentes contra el único repositorio. Así que, básicamente, tiene dos opciones:

1. Palo al control de versiones centralizado y permitir el acceso externo al repositorio (la mayoría de los routers y firewalls permiten redirigir puertos específicos por lo que no debería ser un gran problema).
2. Cambiar al control de versión distribuida (Git, Mercurial, Bazaar ...).

Cualquier otra cosa sería una solución complicada.

Answer 3

• Puede configurar una VPN y dejar que se comprometan directamente con el maestro.
• Puede cambiar hacer una distribuida VCS como Git.
• Puede configurar otro SVN para ellos y fusionarlos. Creo que implicaría un gran dolor de cabeza.

Answer 4

una consideración importante para usted debe ser:

si usted está buscando en los desarrolladores que trabajan y confirmación de los cambios que hacen a su código regularmente - a continuación, SVN es buena.

si está buscando desarrolladores que trabajen en trozos grandes solos y quieran fusionar su base de código una vez que estén seguros de la integridad de las cosas en las que trabajaron, vaya con Git o Mercurial.

También me gustaría añadir que Git puede hacer un poderoso buen trabajo incluso con la integración continua, sin embargo, si sus desarrolladores están más familiarizados con las herramientas basadas en SVN, entonces puede que no sea que útil para incurrir en los gastos generales de hacerles aprender una nueva herramienta.

Answer 5

Un repositorio VCS distribuido por separado (Git, Mercurial, Bazaar) podría tener commit commits que envían parches a un gatekeeper (persona con acceso svn) para incorporar contribuciones distribuidas del desarrollador.

Los ganchos de actualización/clonación/descarga en el VCS distribuido también podrían actualizarse/extraerse/fusionarse desde el repositorio svn, manteniendo su VCS distribuido sincronizado con svn.

Este enfoque mantendría su servidor svn y el proceso de flujo de trabajo y copia de seguridad que funciona para usted ahora. Solo los nuevos desarrolladores distribuidos deben aprender un nuevo VCS (Bazar, Git, etc.).

Tengo que hacer esto en un proyecto ahora, y actualizaré con detalles.