¿Razones específicas para seguir usando Subversion? [cerrado]

22

Quiero elegir un sistema de control de versiones para mi empresa. Hasta ahora sé que tengo Git, Subversion y Mercurial.

En estos días veo que Git es el más utilizado, así que me pregunto: ¿habría alguna razón específica para seguir usando Subversion, o debería ir directamente a Git?

version-control git svn usuario1179459
fuente
36
Ambos trabajan. Lo importante es si cumplirán con sus requisitos, lo cual no nos ha dicho.
Matthew Flynn
66
Consulte ¿Por qué usar SVN? ¿Hay profesionales ocultos (sobre GIT / Mercurial / Bazaar) allí? en desbordamiento de pila.
detly
11
¿En qué argumento excluye Mercurial?
mouviciel
8
-1 para redacción subjetiva (cebo en mi humilde opinión) y "Esos días veo que Git es el más utilizado" - cita necesaria. Git es extremadamente común en el mundo de código abierto, pero en el espacio corporativo es mucho más raro. A los cuerpos realmente les gusta la idea de un repositorio único, central y autorizado y son muy lentos para cambiar. En el espacio corporativo, es más probable que vea buenos CVS viejos que SVN incluso, no importa un DVCS.
Keith
44
@RobinWinslow: SVN es diferente de Git. Se adapta mejor a algunas circunstancias y peor a otras. Personalmente, prefiero DVCS en general y obviamente prefieres Git, pero ambas son opiniones subjetivas. No carecen de valor, pero no pertenecen a un sitio como este.
Keith

Respuestas:

46

SVN no está muerto en absoluto. Todavía tiene un uso extremadamente amplio, y no irá a ningún lado en el corto plazo. SVN es mucho más simple de usar que el control de versión distribuido, especialmente si en realidad no está ejecutando un proyecto distribuido que necesita control de versión distribuido.

Si solo tiene un repositorio central (que es todo lo que su empresa necesitará si todavía son lo suficientemente pequeños como para sobrevivir sin control de fuente hasta ahora), es mucho más simple usar SVN para interactuar con él. Por ejemplo, con SVN puede extraer cambios del repositorio o confirmar sus cambios locales en él, con una sola operación, mientras que HG y Git requieren dos o tres pasos para hacer el trabajo equivalente.

Y con las revisiones recientes, SVN ha solucionado muchos de los problemas de rendimiento que hicieron que las personas prefirieran HG y Git. Es significativamente más rápido ahora que hace un par de años, y en este punto, realmente no hay una buena razón para mirar HG o Git para su proyecto a menos que realmente necesite las características avanzadas de control de versiones distribuidas.

Mason Wheeler
fuente
16
No estoy totalmente de acuerdo con su estimación, pero me gustaría agregar un punto importante a favor de SVN: muchas personas en la industria se sienten cómodas con SVN pero no conocen a Git lo suficiente como para trabajar cómodamente con él. Si todo su equipo está acostumbrado a SVN, cambiar a Git podría tener un costo considerable. (Lo contrario también puede ser cierto, por supuesto).
Joachim Sauer
8
Votaría esta docena de veces si pudiera. Muchas personas siguen la moda, pero realmente no piensan por qué necesitarían un control de fuente distribuido.
Eufórico
21
@Euphoric: sé exactamente por qué siempre quiero un control de fuente distribuida en cada proyecto. Tiene el importante efecto secundario de hacer que la ramificación y la fusión sean simples, obvias y confiables. Subversion todavía está empantanado en casos de esquina con ramificación porque el modelo básico que eligió simplemente lo hace más complicado.
Jan Hudec
18
El control de versión distribuido no es una "moda". Es una evolución del control de fuente, al igual que el control de versiones concurrentes fue una evolución sobre el paradigma de bloqueo de archivos.
JesperE
66
@MichaelBorgwardt, en realidad lo hice varias veces. Es mucho más fácil que con la subversión, el hecho de que todo sea local ayuda mucho, no hay necesidad de explicar la interacción "cliente" y "servidor". El flujo de trabajo en git o hg es mucho más natural e intuitivo (si se mantiene alejado de las partes difíciles como la edición del historial).
SK-logic
19

Las herramientas del cliente aún no se han mencionado. Ciertamente puede hacer todo con un script de línea de comandos, pero tener la integración de la GUI puede ser un verdadero aumento de la productividad.

Trabajamos principalmente con Visual Studio; La integración en el IDE es definitivamente mejor con SVN que con Git en este momento. Esto puede cambiar en el futuro, pero ciertamente consideraría esto en su decisión tanto como las funciones de control de versiones.

Al igual que todo lo demás, un sistema de control de versiones no es un objetivo en sí mismo, solo una herramienta para llevarte a donde vas. Elija el que lo llevará más rápido según su situación.

njr101
fuente
Este es un buen punto. Creo que una de las razones por las cuales las personas prefieren Git a SVN es que Git tiene mejores herramientas de CLI. Pero esto se puede compensar con una buena GUI SVN de terceros, como TortoiseSVN en Windows.
Eufórico
2
Esta es una de las razones por las que elegimos Mercurial (y TortoiseHg) sobre Git. Las ventajas del control de versiones distribuidas y las herramientas decentes y la integración IDE.
HappyCat
15

Soy fanático de Git. Recientemente tuve que admitir que uno de los inconvenientes de Git es que identifica versiones con hashes como opuestos a los números de lanzamiento de svn. El número de versión se puede transmitir más fácilmente por teléfono o algo así.

Y ese es el único profesional que puedo imaginar. Si realmente desea confiar en esa característica, puede tenerla en un Bazar VCS distribuido y / o centralizado . En Git hay etiquetas que pueden servir para ese propósito.

De todos modos, no podía imaginarme desarrollar sin un cambio rápido de rama y escondite. Estas dos características solo superan a SVN, donde, hasta donde recuerdo, la misma tarea requería crear y verificar un árbol completo en directorios separados para lograr el mismo objetivo.

Las llamadas "funciones avanzadas de control de versiones distribuidas" vienen con el tiempo, y no tiene que aprenderlas desde el principio. No les tengas miedo. Están aquí para ayudarlo, no para interferir. Y no hay problema para configurar un repositorio central para un DVCS.

Rajish
fuente
1
Esto es realmente discutible, git solo necesita una parte lo suficientemente grande del hash para poder desambiguar, por lo general, algo ~ 6 caracteres es suficiente, no todo el hash.
TC1
2
En la práctica, nunca pasas el git hash. Puede usar cualquier prefijo único del hash, que generalmente tiene entre 6 y 7 caracteres.
JesperE
1
@JesperE: Sí, pero los números de lanzamiento de SVN aumentan secuencialmente con el tiempo, mientras que los hash de Git, incluso si los abrevia, podrían ser aleatorios.
Keith Thompson
2

Con SVN, puede retirar fácilmente partes de un repositorio hasta el nivel de carpeta, mientras que con git, obtiene todo el repositorio, incluido todo el historial.

Dependiendo de la situación, esto puede tener algunas ventajas para SVN

(esto también tiene algunos grandes inconvenientes, como la basura ".svn" oculta hasta el árbol de carpetas).

Richard Nichols
fuente
3
nota: no .svn basura desde v1.7 - ahora está todo almacenado en una sola ubicación.
gbjbaanb
Esto no es correcto: git le permite retirar solo los archivos, sin el historial, y también es posible retirar solo partes de los archivos de repositorio si lo desea. Es un poco más complejo que svn, pero la capacidad está ahí.
Benubird
2

"Si tiene una tarea que se puede hacer en seis horas, es mejor escribir una herramienta que lo haga en 20 minutos, incluso si la creación de la herramienta lleva seis horas".

El control de versión distribuido es una bestia diferente para abordar. Requiere un aprendizaje sustancial para cada desarrollador. Si tiene el búfer para acomodar el proceso de aprendizaje para cada desarrollador, debe pasar a un buen sistema de control de versiones distribuido. Una vez que finaliza la fase de aprendizaje, el Control de versiones distribuido es mucho mejor que el Control de versiones centralizado.

El Control de versiones distribuido parece ser una eventualidad. Está aquí para quedarse por mucho tiempo, es mejor que nos adaptemos más temprano que tarde. Recuerdo la misma discusión cuando SVN era nuevo y la gente estaba acostumbrada a CVS, se dieron muchos argumentos para no usar SVN, pero finalmente SVN se convirtió en el sistema de control de versiones más popular.

Si la compañía está bien establecida con una gran cantidad de código fuente en el sistema de control de versiones existente, pasar a un nuevo sistema es una gran tarea, pero si la compañía es pequeña o está comenzando, pasar a un nuevo control de versiones es muy fácil. Pero si se apega a un control de versión anterior (en una nueva configuración), llegará al cuello de botella en algún lugar en el futuro en el que tendrá que planificar eventualmente una migración de control de versión de todos modos.

He visto muchos comentarios pro SVN, pero todos tienden a ser de la naturaleza "SVN no es malo" en lugar de "SVN es mejor". Por lo tanto, recomiendo encarecidamente que elija un Control de versión distribuido (como Git) para su proyecto.

EDITAR Ventajas de GIT sobre SVN

  1. No se requiere un servidor dedicado En realidad, ambos se pueden usar sin un servidor.
  2. Puede continuar el desarrollo incluso sin una conexión de red.
  3. La gestión de sucursales es mucho más fácil.
  4. Mejor soporte de herramientas de CI como Bamboo

Alguien mencionó las herramientas (para Visual Studio) como una razón para apegarse a SVN. http://gitscc.codeplex.com/ proporciona soporte GIT para Visual Studio.

Apeirogon Prime
fuente
66
SVN hace mango archivos binarios mejor que Git o Hg.
Nombre falso el
2
"Llegará al cuello de botella en algún lugar en el futuro donde eventualmente tendrá que planificar una migración de control de versiones ..." Lo siento, no puedo aceptar que esta sea una buena razón para hacer el movimiento hoy. He trabajado en muchos proyectos en los que este enfoque lleva a complicar las cosas más de lo necesario y el proyecto se cancela mucho antes de que pueda aprovechar esos beneficios futuros. A veces lo suficientemente bueno, es lo suficientemente bueno. Quédese con YAGNI y tome lo que hace el trabajo hoy. Ya habrá tiempo suficiente para preocuparse por las migraciones más tarde. Al menos aún tendrás un proyecto.
njr101
2
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.Estoy completamente en desacuerdo con esto. Puede tener algunos beneficios percibidos en algunas circunstancias, pero algo tan simple como el número de versión en ser legible para humanos es un beneficio masivo en muchas organizaciones.
TZHX
1
@apeirogon: todo se reduce a lo que vas a poner en el repositorio. ¡El HEAD solo de uno de los repositorios principales con los que trabajo es de 11.1 GB! Si lo tuviera en un repositorio Git / bzr / hg, probablemente tomaría más de 100 GB.
Nombre falso el
1
Por supuesto, esto se debe a que este repositorio en particular está lleno de archivos PCB y modelos 3D, que son todos de formato binario y no son muy eficientes en cuanto al espacio. La recomendación aquí (Electronics.SE, por ejemplo, para las personas que almacenan archivos de diseño de PCB, etc.) es muy diferente si es para alguien que almacena el código fuente.
Nombre falso
1

¿habría alguna razón específica para usar Subversion esos días?

Aparte del soporte de herramientas en IDEs (que no uso), en realidad no, no. Por supuesto, SVN puede ser más familiar, pero esa es la única razón, y he encontrado que Hg y Git son muy fáciles (y muy rápidos) de aprender.

Sí, existen todas esas guías complejas que describen cómo Git es trivial una vez que entiendes que las ramas son solo endofunctores homeomórficos que mapean submanifolds de un espacio de Hilbert. 1

No entiendo eso ¿Pero sabes que? No importa. No necesitas saber nada de eso para usar Git.

En su mayor parte, Git y Hg son fáciles de usar y tienen ventajas definitivas sobre SVN. El elefante en la habitación, por supuesto, se está ramificando: las ramas solo funcionan en Git y Hg. Por el contrario, en SVN son dolorosas en el mejor de los casos y rotas en el peor (fusionando varias cabezas).

Por supuesto, todavía puedes usar SVN. También puedes seguir usando Windows XP. Sin embargo, la mayoría de los usuarios que han probado ambos están de acuerdo en que una de las alternativas es muy superior.

1 Sí, entiendo que esto es una broma. Yo creo que.

Konrad Rudolph
fuente
¿Un tutorial de Git con endofunctores homeomórficos que mapean submanifolds de un espacio de Hilbert? ¡Necesito leer eso! Pero, ¿no se aplica esto a Darcs, que está escrito en Haskell (al que creo que se refiere endofunctor ) e inspirado en la mecánica cuántica (de ahí el espacio de Hilbert )? Realmente no puedo ver qué tienen que ver Git y HG con estas cosas.
Leftaroundabout
@leftaroundabout Es una broma. La descripción ni siquiera es precisa (que yo sepa). Es un riff en los muchos tutoriales que comienzan con "las ramas de git son fáciles una vez que te das cuenta de que ..." y luego hay una compleja metáfora específica de dominio después.
Konrad Rudolph el
1
¿Alguna vez has considerado que todos esos tutoriales demasiado complicados existen por alguna razón? ¿Y para qué sirve? Nunca he entendido la obsesión que tiene la multitud de DVCS con ramificar y luego reintegrar una rama para cada pequeña cosa. Eso siempre me pareció una solución en busca de un problema. Reintegrar una sucursal en SVN es difícil porque eso es algo realmente tonto y conceptualmente incorrecto en primer lugar , y realmente no encuentro ningún argumento que se reduzca a "nuestro producto hace que hacer lo incorrecto sea mucho más fácil" Muy persuasivo.
Mason Wheeler
1
En cuanto a trabajar en múltiples cambios en paralelo, admito que es un poco doloroso, pero la solución correcta es dejar de lado, que está planeado para el próximo lanzamiento de SVN. Y la mayoría de las veces, si está trabajando en múltiples cambios al mismo tiempo (¡y especialmente si lo está haciendo de manera consistente!) Eso es evidencia de un problema más amplio que debería abordarse a nivel de la organización, no habilitado con nuevos herramientas. (Ver arriba, re "nuestro producto hace que hacer las cosas incorrectas sea mucho más fácil", y el clásico artículo de Joel sobre el cambio de tareas humanas).
Mason Wheeler
3
@KonradRudolph La fusión de ramas en el tronco funciona bien en las últimas versiones de SVN. Ha estado mejorando constantemente durante varios años hasta donde ahora es muy bueno.
Adam Bruss