Pregunta ¿Podemos finalmente pasar a DVCS en el software corporativo? ¿SVN sigue siendo un 'must have' para el desarrollo? [cerrado]


Git / Mercurial se han vuelto cada vez más populares. He visto muchos artículos que comparan SVN con Git / Mercurial, pero me pregunto si realmente hay alguna razón para seguir usando SVN. Parece que hay muchas herramientas para Git / Mercurial ahora que deberían ayudar a difundir su adopción corporativa.

¿Hay alguna razón para seguir usando SVN? ¿Mercurial / Git finalmente está listo para la adopción corporativa?


31
2017-08-30 03:49


origen


Respuestas:


Por un lado, la integración de SVN (con IDE, frameworks, wikis, ...) es muy madura, así como sus GUI y navegadores de códigos (aunque DVCS como Git y Mercurial progresan todos los días).

Por otro lado, la introducción de un DVCS en un entorno empresarial todavía no es una tarea trivial:


Para ser claro, usando un DVCS puede ser una opción muy válida:

  • para nuevo proyecto, dónde los desarrolladores no están vinculados con herramientas o procesos heredados
  • especialmente cuando los desarrolladores no están ubicados geográficamente en el mismo lugar (a menudo es el caso del desarrollo de fuente abierta, razón por la cual los DVCS se usan principalmente allí).

StackOverflow (no es un proyecto de código abierto) está usando Mercurial (ver HgInit, escrito por Joel Spolsky)
Migraron de SVN a DVCS:

  • en parte porque sus desarrolladores ahora están en todo el mundo (!)
  • y también porque las instalaciones de fusión de un DVCS son mucho más avanzadas que en SVN.
    (que necesitan para mantener muchas versiones paralelas ligeramente diferentes de su base de código, entre sitios SO, sitios StackExchange V1 y V2, Área 51, ...)
    Ver "diferencias entre DVCS y CVCS"o"¿Cuáles son los beneficios de Mercurial o git sobre svn para ramificación / fusión?".

  • Para ambiente corporativo (donde estoy), cualquier transición de cualquier tipo no es trivial, porque necesita ser:

    • fundado (dinero, incluso si las herramientas son gratuitas)
    • soportado (eso significa tener las personas adecuadas con las competencias adecuadas)
    • integrado (con herramientas heredadas existentes, GUI, IDEs como un Visual Studio u otros muchos, ...)
    • administrado (en términos de servidores comunes, incluso para un DVCS)
    • documentado (especialmente para usuarios que vienen con un CVCS como fondo SVN)

Entonces DVCS también puede ser muy útil en un entorno corporativo:
(Ver "Tasa de adopción corporativa de Git?"o"Control de fuente basado en Git en la empresa: ¿herramientas y prácticas sugeridas?".)
Es (incluso para proyectos nuevos) simplemente no tan fácil de poner en su lugar como en una estructura más pequeña o en entornos de código abierto.


101
2017-08-30 04:21



¿Se considera mejor para un solo desarrollador?

En todo caso, Subversion es peor para un único desarrollador (más difícil de configurar).

Pero una buena razón para seguir usando SVN es la inercia. Si SVN funciona bien para su proyecto (o en su empresa), no hay necesidad de pasar por la molestia de cambiar. Puede haber algunos costos de capacitación involucrados en enseñar a todos las nuevas herramientas (y nuevos flujos de trabajo), sin beneficios reales.


22
2017-08-30 03:57



Creo que Subversion todavía funciona mejor que Mercurial y Git para archivos de gran tamaño como activos multimedia, archivos de Photoshop, composites de After Effects, etc. Recuerdo que Linus Torvalds mencionó los archivos grandes como uno de los pocos problemas potenciales con Git en este Google Tech Talk. Mercurial tiene algunas extensiones para almacenar archivos grandes fuera de un repositorio. Parece que ambos sufren degradación del rendimiento y otros problemas en ese escenario.

Subversion, por otro lado, está siendo utilizado por la corriente Blender Open Movie Project. No creo que lo usen para almacenar los marcos representados, ya que eso sería al menos unos pocos gigabytes de datos para cada pase de renderizado. Pero aún así, con todas las escenas en 3D, objetos, plataformas, texturas y scripts, sigue siendo un gran repositorio con muchos archivos grandes.


12
2017-08-30 04:17



Puedo ver razones por las que podrías continuar para usar SVN si lo ha estado utilizando durante mucho tiempo. Especialmente en una empresa pequeña o círculo de codificación, la transición de SVN a Git o Mercurial, cuando es posible que no esté utilizando ninguna de las funciones más potentes de ellos, puede hacer que sea adverso a realizar el cambio. Como señaló Thilo, una compañía grande que usa SVN va a encontrar ese cambio monumental.

Además, creo que SVN todavía tiene lugares, particularmente cuando se trata de enseñar control de revisiones. Pero eso está tomando mi propia experiencia personal de aprender SVN en la universidad versus enseñarme a mí mismo, así que mis opiniones no serán objetivas sobre eso.

Dicho esto, si estuviera comenzando un repositorio de rasguñoNo puedo pensar en ninguna condición donde puedas decidir que SVN es absolutamente necesario. Tal vez cuando se trata de sistemas heredados.

o usuarios heredados;)


11
2017-08-30 03:57



No sé de ningún intrínseco razones para preferir las vcs centralizadas, existen muchos factores extrínsecos como sistemas heredados, inercia gerencial, curva de aprendizaje, etc.

DVCS se está demostrando a sí mismo como la "mejor ratonera".


9
2017-08-30 03:56



La verdadera pregunta no es SVN vs. Git / Mercurial, es distribuida vs. centralizada. Centralizado puede ser mejor en algunas situaciones, como en un entorno corporativo donde se necesita un control estricto y un registro completo.


8
2017-08-30 04:37



Usamos la subversión como almacenamiento de datos, que no es trivial para fusionar (hacemos desarrollo de hardware, y los archivos de diseño son un formato binario no documentado). SVN tiene la ventaja de que puede establecer bloqueos en los archivos, por lo que solo un desarrollador puede trabajar en un archivo, y también se ve obligado a verificar el archivo más nuevo antes de la edición.


7
2017-08-30 12:41