¿Debo buscar 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 proyectos. Con SVN es realmente fácil 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 y nunca me ha fallado.

¿Hay algo mejor? ¿Me falta alguna característica de otro producto que podría utilizar para hacer mi vida más fácil? Siempre trato de 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 origen que se consideran "estándar de la industria" y hacen las cosas mejor que SVN?

Answer 1

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

Si está realizando un trabajo independiente, a veces llamado "modo avión", como cuando está en un avión y no puede comprometerse, eche un vistazo al Bazar. He encontrado que es más fácil aclimatarse que Git o Mercurial.

Si siempre está trabajando conectado a la red, y usted es el único desarrollador, entonces probablemente pueda seguir con Subversion.

Además, tenga en cuenta el valor de keeping your home directory in Subversion.

Answer 2

Yo personalmente me quedaría con Subversion. Desde un punto de vista profesional, he visto muchos más puestos de trabajo preguntar (y saber) qué Subversion se comparó con GIT. También hay muchas herramientas de código abierto y freeware construidas alrededor de Subversion, sin mencionar la gran comunidad de Subversion.

El control de código fuente no siempre se trata de lo último y mejor, sino que se trata más a menudo de lo que se intenta y es verdad.

Answer 3

Éstos son 3 reasons to switch to git from Subversion (de MarkMcB):

• , fáciles de sistema de no-archivo de base, ramas sin fin, locales
• Stashing trabajo temporal
• Colaboración antes pública se compromete

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

Answer 4

Mercurial también vale la pena considerarlo; la bifurcació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 pasé de SVN a Mercurial.

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

De todos modos, crear un repositorio Mercurial desde un SVN es trivialmente fácil ... pruébalo y mira si te conviene o no .

Answer 5

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

Subversion es un excelente sistema de control de versiones, y usted está contento con él, así que si lo que busca es más, puedo recomendarle información sobre Continuous Integration, hay muchas herramientas que pueden ayudarlo a crea compilaciones automáticas, realiza autoevaluaciones de tus compilaciones, verifica la integridad de cada confirmación y mucho más ...

Answer 6

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 características poderosas no se aplican a tu situación. Sí, la gente discutirá conmigo sobre esto, sin embargo, impulsarán esta característica o aquella que seguramente no necesitas. 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 problemático, en este caso el control de fuente, sin embargo, debe equilibrar el desarrollo personal, las mejoras de proceso/práctica y la entrega del producto 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 las soluciones, pero quédese con lo que funciona por el momento.

Answer 7

Mercurial

he utilizado principalmente CVS y SVN, feliz y contento, entonces me puse a investigar control de fuente distribuido, ya que había un montón de alboroto hecho sobre DSVC. Después de usar DSVC noté un cambio en mi estilo de desarrollo, me volví más fluido y adaptable. Permitiéndome fusionar de nuevo en el tronco o rama experimental sin dolor.

• Mercurial puede escalar de una banda de un hombre a grande, es decir, OpenJDK, sin mucho dolor de cabeza.
• Mercurial es rápido, tal vez no tan rápido como GIT, pero aún así es muy 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 menor que GIT, después de algunos documentos leídos se obtiene el jist básica de las cosas (http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/)
• hg permite (también lo hacen muchos DSVCs) hacer interfaz con un corporativo de control SVN Fuente con hg-SVN y hgsubversion que es una maravillosa extensión con permite y cajas, pero aún no empujar o comprometer la funcionalidad
• Usted puede también configurar una carrera de empuje servidor HTTP y tire a través de SSH
• también tienen la opción realmente ordenado de conseguir junto con sus amigos de codificación y simplemente inicie el servidor HTTP, ejecútelo en localhost y sus compañeros pueden empujar y jalar mientras realiza un sprint de código.
• También puede ver el estado actual del proyecto a través de esta página HTTP.
• por último vistazo aquí para una breve descripción de los comandos simples (http://edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf)

Git

• probado, su apoyo a SVN es mejor que mercurial.pero desde hgsubversion está en alza y se está convirtiendo en competencia para git svn.

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

BZR

• nunca había probado

I havnt miró hacia atrás desde que empecé con HG

Answer 8

Regla no. 1: "Nunca cambie un sistema en funcionamiento"

También, ya que hay muchas nuevas soluciones brillantes (para los problemas que no tienen, a medida que trabaja solo) debe tener en cuenta el coste de cambiar a un nuevo VCS: La importación de subversión a Mercurial/git no es una tarea fácil

no hay herramienta (AFAIK), que importa svn repos mediante el formato dumpformat. Por lo tanto, si no utiliza el formato de volcado, se adhiere a todas las ramas/etiquetas de svn y las agrega a git/BZR/Mercurial manualmente/a través del script

Así que no sé cuán grandes son sus repos (mis repos son que van desde 20 MB a 24 GB), pero llevará un largo tiempo para verificar un repositorio completo e incluso los proyectos pequeños con muchas etiquetas consumirán una gran cantidad de espacio en el disco duro .

Problema adicional es el tiempo hasta que la migración finalice y no pueda seguir trabajando.

Answer 9

Si SVN satisface todas sus necesidades, entonces no veo el motivo para el cambio. Si la curiosidad es el motor de su búsqueda de un control de origen diferente, le recomendaría leer acerca de 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 esté en su situación) .

Answer 10

Hay un viejo proverbio yanqui.

Si no está roto, no lo arregles.

Answer 11

Soy igual que usted en el tema de la investigación constante para obtener la mejor herramienta.

Probé SVN para trabajo SOLO y alguien me recomendó Mercurial (hg). Ahora hago keynotes sobre eso. Es más amigable que git en windows. Ahora pienso "¿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, su informe está en su máquina local. Por lo tanto, es muy rápido para un registro, o diff o historial.

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

Answer 12

Definitivamente vale la pena buscar en VC "distribuido", incluso si no está utilizando realmente un flujo de trabajo distribuido. Ser capaz de tener ramas 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 normales SVN, por lo que teníamos un flujo de trabajo normal y centralizado), y funcionó bastante bien.