tortoise - ¿Podemos finalmente pasar a DVCS en el software corporativo? ¿SVN sigue siendo un ''must have'' para el desarrollo?
tortoise merge (11)
¿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.
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?
¡Subversion se integra muy bien con Apache!
Creo que Subversion todavía funciona mejor que Mercurial y Git para archivos grandes como activos multimedia, archivos de Photoshop, compuestos 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 el actual 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.
La subversión es ideal cuando el paradigma centralizado es ideal.
Una de esas situaciones es cuando se trabaja en papeles. Tiene mucho más sentido simplemente mantener una copia maestra de la que todo el mundo extrae. No queremos crear ramas o etiquetas. Solo queremos hacer un seguimiento de quién hace un cambio y luego propagarlo a todos los autores.
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.
Mi respuesta se basa en algunas suposiciones:
- El tema que está almacenando en el control de la fuente es el código fuente, y lo que está haciendo con el código es el desarrollo de software profesional .
- Siempre debe usar la mejor herramienta para el trabajo; Como dice Joel Test, debes usar las mejores herramientas que el dinero puede comprar , incluso si son gratuitas.
- Los factores externos son irrelevantes para elegir cuál es la mejor herramienta para el trabajo: estos son los obstáculos que debe superar para la adopción. Esas razones, mientras tanto, son excusas para seguir utilizando Subversion, no son razones por las que debería usarlo explícitamente.
En segundo lugar, que un DVCS se considera una herramienta mejor y más poderosa que Subversion. Se ha discutido mucho sobre el Desbordamiento de pila en el pasado, y otras respuestas han intervenido diciendo que la mayoría de la gente está de acuerdo en que el DVCS es "la mejor trampa para ratones". No creo que sea necesario probar este punto; puede leer detenidamente las preguntas relacionadas / similares ya publicadas aquí. Por supuesto, no todos los DVCS serán mejores que Subversion en todos los aspectos, pero creo que DVCS líderes como Mercurial, git, etc. son mejores que Subversion en casi todos los aspectos.
Entonces, según mi lógica, si vas a elegir la mejor herramienta para el trabajo y Subversion es una herramienta inferior, ya no se debe usar Subversion. Eso no significa que veremos una adopción instantánea y mundial, pero mi opinión es que si crees en usar la mejor herramienta para el trabajo, todas las organizaciones deberían planear pasar a DVCS. Por supuesto, muchos no lo harán, y espero que las personas continúen utilizando Subversion durante mucho tiempo.
No conozco ninguna razón intrínseca para preferir vcs centralizados, 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".
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:
- Algunos requisitos no se cumplen fácilmente (en términos de seguridad y control de acceso, administración y restricción de acceso)
- El paradigma DVCS es más complejo de entender , con muchos pros y contras .
- Realmente necesita aprovechar sus muchos flujos de trabajo en lugar de confiar en el SVN centralizado.
- La transición de CVCS a DVCS es difícil
Para que quede claro, usar un DVCS puede ser una opción muy válida :
- para un nuevo proyecto , donde 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 el caso con el desarrollo de código abierto, por lo que los DVCS se usan principalmente allí).
(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, ...)
Consulte " diferencias entre DVCS y CVCS " o " ¿Cuáles son los beneficios de Mercurial o git sobre svn para la bifurcación / fusión? ".Para un entorno corporativo (donde estoy), cualquier transición de cualquier tipo no es trivial , porque debe ser:
- financiado (dinero, incluso si las herramientas son gratuitas)
- compatible (eso significa tener las personas adecuadas con las competencias adecuadas)
- integrado (con herramientas heredadas existentes, GUI, IDE como 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:
(Consulte " 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.
Puede usar tanto Git como Hg como clientes SVN. Eso significa que puedes tener lo mejor de ambos mundos.
Sin embargo, no puede usar SVN como cliente para Git o Hg.
En muchos sentidos, el caso ideal es un repositorio SVN central con usuarios que usan cualquier DVCS que quieran como cliente.
SVN es mucho más fácil de aprender y usar para muchas personas, y sus herramientas son mucho más maduras.
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.
Veo razones por las que puede continuar usando 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 desde cero , no puedo pensar en ninguna condición donde pueda decidir que SVN es absolutamente necesario. Tal vez cuando se trata de sistemas heredados.
o usuarios heredados;)