tortoise - svn tutorial español
¿Debería ver los sistemas de control de versiones más allá de Subversion? (12)
Aquí hay 3 razones para cambiar a git desde Subversion (desde MarkMcB):
- Ramas locales interminables, fáciles, no basadas en el sistema de archivos
- Atasco de trabajo temporal
- Colaboración antes de confirmaciones públicas
(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).
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 que haga 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?
Git, Mercurial y Bazaar son sistemas de control distribuidos que operan con la idea de que usted no siempre está conectado a la red, y que no es necesario que haya una versión central del repositorio.
Si estás haciendo un montón de trabajo independiente, a veces llamado "modo avión", como cuando estás en un avión y no puedes comprometerte, echa un vistazo al Bazar. He encontrado que es más fácil aclimatarse que Git o Mercurial.
Si siempre estás trabajando conectado a la red y eres el único desarrollador, entonces probablemente puedas quedarte con Subversion.
Además, considere el valor de mantener su directorio personal en Subversion .
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, control de fuente, 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 las soluciones, pero quédese con lo que funciona por el momento.
Mercurial también merece consideración; 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 repo de Mercurial desde un SVN es trivialmente fácil ... pruébalo y ve si te conviene o no.
También personalmente 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 está buscando más, puedo recomendarle que obtenga información sobre la Integración Continua , hay muchas herramientas que pueden ayudarlo a hacer compilaciones automáticas, Realice autoevaluaciones de sus compilaciones, verifique la integridad de cada compromiso y mucho más ...
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 la fuente no siempre se trata de lo último y mejor, sino más a menudo de lo que se intenta y es verdad.
Hay un viejo proverbio yanqui.
Si no está roto, no lo arregles.
Si SVN satisface todas sus necesidades, entonces no veo la razón del 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 que dudo que sea en su situación).
Soy como tú en el tema de la investigación constante para obtener la mejor herramienta.
Intenté SVN para el 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 servidores que admitan mercurial para una versión en línea de su repositorio.
Mercurial
Principalmente utilicé CVS y SVN, contento 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 fusionar de nuevo en el tronco o rama experimental sin dolor.
- Mercurial puede escalar de una banda de un hombre a una enorme, es decir, OpenJDK, sin mucho dolor de cabeza.
- Mercurial es rápido, tal vez no tan rápido como GIT, pero todavía 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 leer algunos documentos se obtiene la información básica ( http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ )
- hg permite (al igual que muchos DSVC) que interactúes con un control SVN Source corporativo con hg-svn y hgsubversion, que es una extensión maravillosa con permisos y paros, pero que aún no empuja o no confiere funcionalidad
- También puede configurar un servidor HTTP ejecute push y pull a través de SSH
- también tienen la opción muy buena de reunirse con sus amigos de codificación y simplemente iniciar el servidor HTTP ejecutarlo en localhost y sus compañeros pueden empujar y tirar 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, 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 desde hgsubversion está en alza y se está convirtiendo en competencia para git svn.
Git es genial, pero necesitas mantener constantemente tu código fuente depo y volver a empaquetarlo. Como consta de muchos scripts bash, tiene problemas para ejecutarse en Windows. Pero es sorprendentemente rápido, con muchas funciones para que uses. En realidad, la cantidad de características puede ser una desventaja.
BZR
- nunca lo he intentado
No miré hacia atrás desde que comencé con HG
Definitivamente vale la pena buscar VC "distribuido" incluso si no está utilizando 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.
Regla no. 1: "Nunca cambie un sistema en ejecución"
Además, como hay muchas nuevas soluciones brillantes (para problemas que no tiene, ya que trabaja solo) debe considerar el costo 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 importe repositorios svn utilizando dumpformat. Entonces, si no usas el formato dump, te quedarás pendiente de todas las ramas / etiquetas de svn y las agregarás a git / BZR / Mercurial manualmente / a través de un script
Por lo tanto, no sé cuán grandes son sus repos (mis repos van desde 20 MB a 24 GB), pero tomará mucho tiempo verificar un repositorio completo e incluso los proyectos pequeños con muchas etiquetas consumirán una gran cantidad de discos duros. espacio
Problema adicional es el tiempo hasta que la migración finalice y no pueda seguir trabajando.