¿Debo mirar a los sistemas de control de versiones más allá de Subversion?

Question

En el último año me he vuelto adicto a la subversión. Soy un desarrollador único y también trabajo en algunos de mis propios proyectos. Con SVN es realmente fácil de administrar todo, y como está alojado en un servidor en línea a través de HTTPS, puedo acceder a mi código desde cualquier lugar. También es ideal para implementar código en nuestros servidores de producción / desarrollo.

Mi punto es que hace todo lo que necesito que haga y nunca me ha fallado.

¿Hay algo mejor? ¿Me estoy perdiendo alguna característica en otro producto que podría estar usando para hacer mi vida más fácil? Siempre me gusta usar el mejor software y no tengo problemas para migrar a nuevas tecnologías.

He oído hablar de GIT y he hecho algunas investigaciones. Planeo intentarlo, pero mientras estoy jugando con eso, ¿hay otros sistemas de control de fuentes que se consideren "estándar de la industria"? ¿Y hacen las cosas mejor que SVN?

Answer 1

Git, Mercurial y Bazaar son sistemas de control distribuido que operan con la idea de que no siempre está conectado a la red, y que no es necesario que haya una versión central del repositorio.

Si estás haciendo mucho trabajo separado, a veces llamado "modo avión", como si estuvieras en un avión y no puedes comprometerte, mira Bazaar. He encontrado que es más fácil aclimatarse que Git o Mercurial.

Si siempre estás haciendo trabajo conectado a la Red, y eres el único desarrollador, entonces probablemente puedas seguir con Subversion.

Además, considere el valor de mantener su directorio de inicio en Subversion .

Answer 2

Mercurial

Principalmente utilicé CVS y SVN, feliz y contento, luego comencé a investigar el control de fuente distribuida ya que había mucho alboroto sobre DSVC. Después de usar DSVC noté un cambio en mi estilo de desarrollo, me volví más fluido y adaptable. Permitiéndome fusionarme de nuevo en el tronco o la rama experimental sin dolor.

• Mercurial puede escalar de una banda de un solo hombre a una enorme, por ejemplo, OpenJDK, sin mucho dolor de cabeza.
• Mercurial es rápido, tal vez no tan rápido como GIT, pero sigue siendo realmente rápido
• Mercurial Queues es una forma fantástica de administrar parches. A la velocidad de la iluminación engrasada.
• Se puede ejecutar en diferentes sistemas operativos, la compatibilidad es excelente, ya que se basa en Python.
• la curva de aprendizaje es más baja que GIT, después de leer unos pocos documentos, se obtiene el jist básico de las cosas ( http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ )
• hg le permite (al igual que muchos DSVC) que se interconecte con un control SVN Source corporativo con hg-svn y hgsubversion, que es una extensión maravillosa con permisos y verificaciones, pero que aún no está presionando o comprometiendo la funcionalidad
• También puede configurar un servidor HTTP ejecutar push and pull a través de SSH
• también tienen la opción realmente interesante de reunirse con sus amigos de codificación y simplemente iniciar el servidor HTTP ejecutarlo en localhost y sus compañeros pueden presionar y tirar mientras hace un sprint de código.
• También puede ver el estado actual del proyecto a través de esta página HTTP.
• por último, busque aquí una breve descripción de los comandos simples ( http: // edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf )

Git

• Lo intenté, su soporte para svn es mejor que mercurial. pero como hgsubversion está en alza y se está convirtiendo en una competencia para git svn.

Git es genial, pero necesitas mantener constantemente el código fuente y volver a empaquetarlo. Como consta de muchos scripts de bash, tiene problemas para ejecutarse en Windows. Pero es increíblemente rápido, con muchas características para que uses. En realidad, la cantidad de funciones puede ser una desventaja.

BZR

• nunca lo probé

No he mirado atrás desde que empecé con HG

Answer 3

Yo personalmente me quedaría con Subversion. Desde un punto de vista profesional, he visto muchos más empleos pedir (y saber) qué Subversion se comparó con GIT. También hay una gran cantidad de herramientas de código abierto y software gratuito creadas alrededor de Subversion, sin mencionar la enorme comunidad de Subversion.

El control de la fuente no siempre tiene que ver con lo último y lo mejor, sino con más frecuencia con lo que se ha probado y es cierto.

Answer 4

La mejor razón para cambiar es la necesidad. Sin embargo, parece que no hay una necesidad real de cambiar. Eres un " Ejército de Uno " por lo que la mayoría de las funciones potentes no se aplican a su situación. Sí, la gente discutirá conmigo sobre esto, sin embargo, estarán presionando esta característica o esa característica que probablemente no necesite realmente. El tiempo lo es todo, si en el futuro cambian sus necesidades, cambie su solución.

Siempre habrá soluciones mejores o diferentes para un espacio de problemas, en este caso, el control de origen, sin embargo, debe equilibrar el desarrollo personal, las mejoras de procesos / prácticas y la entrega de productos de trabajo. Puede obtener más información sobre las diferentes soluciones / aplicaciones para el control de código fuente para ampliar su conocimiento y reconocer cuándo es el momento de cambiar de solución, pero seguir con lo que funciona por ahora.

Answer 5

Aquí hay 3 razones para cambie a git desde Subversion (desde MarkMcB):

• Ramificaciones locales interminables, sencillas, que no se basan en sistemas de archivos
• Trabajo temporal de ocultamiento
• Colaboración antes de compromisos públicos

(Lea el artículo vinculado para obtener explicaciones completas y comparaciones directas de cómo hacer las tres cosas tanto en git como en Subversion.)

Answer 6

Yo también personalmente me quedaría con Subversion, ¿Hay algo mejor?

Subversion es un excelente sistema de control de versiones, y está contento con él, así que si está buscando más, puedo recomendarle que obtenga información sobre Continuous Integration , existen muchas herramientas que pueden ayudarlo a realizar compilaciones automáticas, realizar autocomprobaciones de sus compilaciones, verificar la integridad de cada compromiso y mucho más. ..

Answer 7

Mercurial también es digno de consideración; La ramificación es mucho más amigable y puede funcionar sin una conexión de red. Nunca intenté seriamente separar el trabajo en ramas hasta que me mudé de SVN a Mercurial.

Lo único que echo de menos en serio es TortoiseSVN; hay un workalike (TortoiseHg) que es bastante bueno, pero no es lo mismo ...

De todos modos, crear un repo de Mercurial a partir de un SVN es trivialmente fácil ... pruébalo y ve si te conviene o no.

Answer 8

Regla no. 1: " Nunca cambie un sistema en ejecución "

Además, como hay muchas soluciones nuevas (para los problemas que no tiene, ya que trabaja solo), debe considerar el costo de cambiar a un nuevo VCS: La importación de subversion a Mercurial / git no es una tarea fácil

no hay ninguna herramienta (AFAIK), que importa svn repos utilizando el dumpformat. Por lo tanto, si no usa el formato de volcado, se pegará a todas las ramas / etiquetas de svn y las agregará a git / BZR / Mercurial manualmente / a través de un script

Por lo tanto, no sé qué tan grandes son tus repositorios (mis repositorios van de 20 MB a 24 GB), pero tomará un largo tiempo para revisar un repositorio completo e incluso proyectos pequeños con muchas etiquetas consumirán una gran cantidad de espacio en el disco duro .

El problema adicional es el tiempo que transcurre hasta que finaliza la migración; no puede continuar trabajando.

Answer 9

Soy como tú en el tema de la investigación constante para obtener la mejor herramienta.

Probé SVN para un trabajo SOLO y alguien me recomendó Mercurial (hg). Ahora hago notas al respecto. Es más amigable que git en las ventanas. Ahora creo que " ¿por qué svn se complica con tareas simples como etiquetas " ;. SVN no sabe qué es una etiqueta. Para SVN una etiqueta es una copia. En mercurial una etiqueta es un alias para una revisión. ¿Qué tan complicado podría ser?

El rendimiento es otro problema. En Mercurial tu repo está en tu máquina local. Así que es muy rápido para un registro, o diff o historial.

Aunque no sé nada acerca de los servidores que admiten mercurial para una versión en línea de su repositorio.

Answer 10

Si SVN responde a todas sus necesidades, no veo la razón del cambio. Si la curiosidad es el motor de su búsqueda de un control de fuente diferente, le recomendaría leer sobre git u otra solución de scm distribuida y tratar de averiguar si vale la pena la inversión para cambiar (lo cual dudo que sea en su situación).

Answer 11

Hay un viejo proverbio yanqui.

Si no está roto, no lo arregles.

Answer 12

Definitivamente vale la pena mirar " distribuido " VC incluso si no está utilizando un flujo de trabajo distribuido. Ser capaz de tener sucursales privadas y controlar tus compromisos locales vale la pena el esfuerzo de aprender git. He estado utilizando principalmente git-svn (con otros miembros del equipo que utilizan clientes SVN normales, por lo que tuvimos un flujo de trabajo normal y centralizado), y funcionó de manera impecable.