¿Cómo usar SVN, Branch? ¿Etiqueta? ¿Maletero?

Estaba buscando en Google un poco y no pude encontrar una buena guía para principiantes de SVN , no en el significado de "¿cómo uso los comandos"? ¿Cómo controlo mi código fuente?

Lo que me gustaría aclarar son los siguientes temas:

• ¿Con qué frecuencia te comprometes? ¿Tan a menudo como se presiona Ctrl+ s?
• ¿Qué es una rama y qué es una etiqueta y cómo se controlan?
• ¿Qué entra en el SVN? ¿Solo el código fuente o también comparte otros archivos aquí? (No se consideran archivos versionados ...)

No tengo idea de qué rama y etiqueta es, así que no sé el propósito, pero mi conjetura es que subes cosas al tronco y cuando haces una construcción importante, ¿lo mueves a la rama? Entonces, ¿qué se considera una construcción importante en este caso?

El libro de subversión es una excelente fuente de información sobre estrategias para diseñar su repositorio, ramificación y etiquetado.

Ver también:

¿Continúas el desarrollo en una rama o en el tronco?

Estrategias de ramificación

Me hice las mismas preguntas cuando vinimos a implementar Subversion aquí: unos 20 desarrolladores repartidos en 4 a 6 proyectos. No encontré ninguna buena fuente con "la respuesta". Estas son algunas partes de cómo se ha desarrollado nuestra respuesta en los últimos 3 años:

- comprometerse con la frecuencia que sea útil; nuestra regla general es comprometerse siempre que haya realizado un trabajo suficiente para que sea un problema tener que volver a hacerlo si se pierden las modificaciones; a veces me comprometo cada 15 minutos más o menos, otras veces pueden ser días (sí, a veces me lleva un día escribir 1 línea de código)

- utilizamos ramas, como sugirió una de sus respuestas anteriores, para diferentes vías de desarrollo; en este momento para uno de nuestros programas tenemos 3 ramas activas: 1 para el desarrollo principal, 1 para el esfuerzo aún no terminado de paralelizar el programa y 1 para el esfuerzo de revisarlo para usar archivos de entrada y salida XML;

- apenas usamos etiquetas, aunque creemos que deberíamos usarlas para identificar lanzamientos a producción;

Piense en el desarrollo siguiendo un camino único. En algún momento o estado de desarrollo, el marketing decide lanzar la primera versión del producto, por lo que coloca una bandera en la ruta etiquetada '1' (o '1.0' o lo que sea). En otro momento, una chispa brillante decide paralelizar el programa, pero decide que eso llevará semanas y que la gente quiere seguir por el camino principal mientras tanto. Entonces construyes una bifurcación en el camino y diferentes personas deambulan por las diferentes bifurcaciones.

Las banderas en el camino se llaman 'etiquetas', y las horquillas en el camino son donde se dividen las 'ramas'. Ocasionalmente, también, las ramas vuelven a juntarse.

- ponemos todo el material necesario para construir un ejecutable (o sistema) en el repositorio; Eso significa al menos el código fuente y el archivo de creación (o archivos de proyecto para Visual Studio). Pero cuando tenemos íconos y archivos de configuración y todo lo demás, eso va al repositorio. Alguna documentación encuentra su camino en el repositorio; Ciertamente, cualquier documentación como los archivos de ayuda que podrían ser parte integral del programa sí lo es, y es un lugar útil para colocar la documentación del desarrollador.

Incluso ponemos ejecutables de Windows para nuestras versiones de producción allí, para proporcionar una ubicación única para las personas que buscan software: nuestras versiones de Linux van a un servidor, por lo que no es necesario almacenarlas.

- no requerimos que el repositorio en todo momento sea capaz de entregar una última versión que construya y ejecute; algunos proyectos funcionan de esa manera, otros no; la decisión recae en el gerente del proyecto y depende de muchos factores, pero creo que se descompone cuando se realizan cambios importantes en un programa.

* How often do you commit? As often as one would press ctrl + s?

Tan seguido como sea posible. El código no existe a menos que esté bajo control de origen :)

Las confirmaciones frecuentes (en adelante, conjuntos de cambios más pequeños) le permiten integrar sus cambios fácilmente y aumentar las posibilidades de no romper algo.

Otras personas notaron que debe comprometerse cuando tiene un código funcional, sin embargo, me parece útil hacerlo un poco más a menudo. Pocas veces me di cuenta de que uso el control de fuente como un mecanismo rápido de deshacer / rehacer.

Cuando trabajo en mi propia sucursal, prefiero comprometerme tanto como sea posible (literalmente con la frecuencia que presiono ctrl + s).

* What is a Branch and what is a Tag and how do you control them?

Lea el libro SVN : es un lugar con el que debe comenzar al aprender SVN:

• ¿Qué es una rama?
• Etiquetas

* What goes into the SVN?

La documentación, los pequeños binarios necesarios para la compilación y otras cosas que tienen algún valor van al control de origen.

Aquí hay algunos recursos sobre frecuencia de confirmación, mensajes de confirmación, estructura del proyecto, qué poner bajo control de origen y otras pautas generales:

• Mejores prácticas de control de versiones (mi propio blog)
• Check in Early, Check in Often (Coding Horror) (los comentarios aquí contienen muchos buenos consejos)
• Política de compromiso de KDE

Estas preguntas de desbordamiento de pila también contienen información útil que puede ser de interés:

• Organizar la base del código fuente al mezclar dos o más lenguajes (como Java y C ++)
• Sugerencias para un buen mensaje de confirmación: ¿formato / directriz?
• ¿Con qué frecuencia cometer cambios en el control de fuente?
• Aprendiendo Control de versiones, y aprendiéndolo bien

Con respecto a los conceptos básicos de Subversion, como la ramificación y el etiquetado, creo que esto está muy bien explicado en el libro de Subversion .

Como puede darse cuenta después de leer un poco más sobre el tema, las opiniones de las personas sobre las mejores prácticas en esta área a menudo varían y a veces son conflictivas. Creo que la mejor opción para ti es leer sobre lo que otras personas están haciendo y elegir las pautas y prácticas que creas que tienen más sentido para ti.

No creo que sea una buena idea adoptar una práctica si no comprende el propósito de la misma o no está de acuerdo con la justificación de la misma. Por lo tanto, no siga ningún consejo a ciegas, sino que decida qué cree que funcionará mejor para usted. Además, experimentar con diferentes formas de hacer las cosas es una buena manera de aprender y descubrir cómo te gusta trabajar mejor. Un buen ejemplo de esto es cómo estructura el repositorio. No hay una forma correcta o incorrecta de hacerlo, y a menudo es difícil saber qué forma prefiere hasta que realmente los haya probado en la práctica.

La frecuencia de compromiso depende de su estilo de gestión de proyectos. Muchas personas se abstienen de comprometerse si se rompe la compilación (o funcionalidad).

Las ramas se pueden usar de una de dos maneras, típicamente: 1) Una rama activa para el desarrollo (y el tronco se mantiene estable), o 2) ramas para rutas de desarrollo alternativas.

Las etiquetas se usan generalmente para identificar lanzamientos, para que no se pierdan en la mezcla. La definición de 'liberación' depende de usted.

Creo que el problema principal es que la imagen mental del control de la fuente es confusa. Comúnmente tenemos troncos y ramas, pero luego obtenemos ideas no relacionadas de etiquetas / lanzamientos o algo a ese efecto.

Si usa la idea de un árbol más completamente, se vuelve más claro, al menos para mí lo es.

Obtenemos el tronco -> forma ramas -> produce fruta (etiquetas / lanzamientos).

La idea es que crezca el proyecto desde un tronco, que luego crea ramas una vez que el tronco es lo suficientemente estable como para sostener la rama. Luego, cuando la rama ha producido una fruta, la arrancas de la rama y la sueltas como una etiqueta.

Las etiquetas son esencialmente entregables. Mientras que el tronco y las ramas los producen.

Como otros han dicho, el Libro SVN es el mejor lugar para comenzar y una gran referencia una vez que haya conseguido sus piernas de mar. Ahora, a tus preguntas ...

¿Con qué frecuencia te comprometes? ¿Tan a menudo como se presionarán las teclas Ctrl + s?

A menudo, pero no tan a menudo como presiona ctrl + s. Es una cuestión de gusto personal y / o política de equipo. Personalmente, diría commit cuando completas un código funcional, por pequeño que sea.

¿Qué es una rama y qué es una etiqueta y cómo se controlan?

Primero, el tronco es donde haces tu desarrollo activo. Es la línea principal de su código. Una rama es una desviación de la línea principal. Podría ser una desviación importante, como una versión anterior, o simplemente un pequeño retoque que quieras probar. Una etiqueta es una instantánea de su código. Es una forma de adjuntar una etiqueta o marcador a una revisión en particular.

También vale la pena mencionar que en subversion, el tronco, las ramas y las etiquetas son solo convenciones. Nada le impide trabajar en etiquetas o tener ramas que son su línea principal, o ignorar el esquema de etiqueta-rama-tronco por completo. Pero, a menos que tenga una muy buena razón, es mejor seguir la convención.

¿Qué entra en el SVN? ¿Solo el código fuente o también comparte otros archivos aquí?

También una elección personal o de equipo. Prefiero mantener todo lo relacionado con la compilación en mi repositorio. Esto incluye los archivos de configuración, scripts de construcción, archivos multimedia, documentos relacionados, etc. Debe no registras archivos que necesitan ser diferente en la máquina de cada desarrollador. Tampoco necesita registrar los subproductos de su código. Estoy pensando principalmente en crear carpetas, archivos de objetos y similares.

Eric Sink, quien apareció en el podcast SO # 36 en enero de 2009, escribió una excelente serie de artículos bajo el título Source Control How-to .

(Eric es el fundador de SourceGear que comercializa una versión de SourceSafe compatible con plug, pero sin la horrible).

Solo para agregar otro conjunto de respuestas:

• Me comprometo cada vez que termino un trabajo. A veces es una pequeña corrección de errores que solo cambió una línea y me tomó 2 minutos hacerlo; otras veces son dos semanas de sudor. Además, como regla general, no confirma nada que rompa la compilación. Por lo tanto, si le ha llevado mucho tiempo hacer algo, tome la última versión antes de comprometerse y vea si sus cambios rompen la compilación. Por supuesto, si paso mucho tiempo sin comprometerme, me pone incómodo porque no quiero perder ese trabajo. En TFS, uso esto como "estanterías" para esto. En SVN tendrás que trabajar de otra manera. Quizás cree su propia sucursal o haga una copia de seguridad de estos archivos manualmente en otra máquina.
• Las ramas son copias de todo su proyecto. La mejor ilustración para su uso es quizás el versionado de productos. Imagine que está trabajando en un proyecto grande (por ejemplo, el kernel de Linux). Después de meses de sudor finalmente has llegado a la versión 1.0 que lanzas al público. Después de eso, comenzará a trabajar en la versión 2.0 de su producto, que será mucho mejor. Pero mientras tanto, también hay mucha gente que está utilizando la versión 1.0. Y estas personas encuentran errores que tienes que corregir. Ahora, no puede corregir el error en la próxima versión 2.0 y enviarlo a los clientes; no está listo para nada. En su lugar, debe extraer una copia antigua de la fuente 1.0, corregir el error allí y enviarlo a la gente. Para eso están las ramas. Cuando soltaste el 1. 0 versión que hizo una rama en SVN que hizo una copia del código fuente en ese punto. Esta rama se llamaba "1.0". Luego continuó trabajando en la próxima versión en su copia de origen principal, pero la copia 1.0 permaneció allí tal como estaba en el momento del lanzamiento. Y puedes continuar arreglando errores allí. Las etiquetas son solo nombres adjuntos a revisiones específicas para facilitar su uso. Podría decir "Revisión 2342 del código fuente", pero es más fácil referirse a él como "Primera revisión estable". :)
• Normalmente pongo todo en el control de origen que se relaciona directamente con la programación. Por ejemplo, como estoy haciendo páginas web, también pongo imágenes y archivos CSS en el control de origen, sin mencionar los archivos de configuración, etc. La documentación del proyecto no entra allí, sin embargo, eso es solo una cuestión de preferencia.

Otros han declarado que depende de tu estilo.

La gran pregunta para usted es con qué frecuencia "integra" su software. Desarrollo impulsado por pruebas, Agile y Scrum (y muchos, muchos otros) se basan en pequeños cambios y una integración continua. Predican que se hacen pequeños cambios, todos encuentran los descansos y los arreglan todo el tiempo.

Sin embargo, en un proyecto más grande (piense en gobierno, defensa, 100k + LOC) simplemente no puede usar la integración continua ya que no es posible. En estas situaciones, puede ser mejor usar la ramificación para hacer muchas pequeñas confirmaciones, pero traer de vuelta al tronco SOLAMENTE lo que funcionará y está listo para integrarse en la compilación.

Sin embargo, una advertencia con la ramificación es que si no se gestionan adecuadamente, puede ser una pesadilla en su repositorio conseguir trabajo en el tronco, ya que todos se están desarrollando desde diferentes puntos en el tronco (que es, por cierto, uno de los argumentos más importantes para integración continua).

No hay una respuesta definitiva a esta pregunta, la mejor manera es trabajar con su equipo para encontrar la mejor solución de compromiso.

Control de versiones con Subversion es la guía para principiantes y viejos.

No creo que pueda usar Subversion de manera efectiva sin leer al menos los primeros capítulos de esto.

Para comprometerme, uso las siguientes estrategias:

• comprometerse tan a menudo como sea posible.

• Cada cambio de función / corrección de errores debe tener su propia confirmación (no confirme muchos archivos a la vez, ya que eso hará que el historial de ese archivo no esté claro, por ejemplo, si cambio un módulo de registro y un módulo GUI de forma independiente y los confirmo a la vez, ambos cambios serán visibles en ambos historiales de archivos. Esto dificulta la lectura de un historial de archivos),

• no rompa la compilación en ninguna confirmación: debería ser posible recuperar cualquier versión del repositorio y compilarla.

Todos los archivos que son necesarios para compilar y ejecutar la aplicación deben estar en SVN. Los archivos de prueba y otros no deberían, a menos que sean parte de las pruebas unitarias.

Aquí hay muchos buenos comentarios, pero algo que no se ha mencionado son los mensajes de confirmación. Estos deben ser obligatorios y significativos. Especialmente con ramificación / fusión. Esto le permitirá realizar un seguimiento de los cambios relevantes para las características de los errores.

por ejemplo, svn commit . -m 'bug #201 fixed y2k bug in code'le dirá a cualquiera que vea el historial para qué fue esa revisión.

Algunos sistemas de seguimiento de errores (por ejemplo, trac) pueden buscar estos mensajes en el repositorio y asociarlos con los tickets. Lo que hace que sea muy fácil determinar qué cambios están asociados con cada ticket.

La política en nuestro trabajo es la siguiente (equipo de desarrolladores múltiples que trabaja en un marco orientado a objetos):

• Actualice desde SVN todos los días para obtener los cambios del día anterior

• Comprométase a diario, de modo que si está enfermo o ausente al día siguiente, alguien más puede hacerse cargo de donde lo dejó.

• No cometas código que rompa nada, ya que eso afectará a los otros desarrolladores.

• ¡Trabaja en trozos pequeños y comprométete diariamente CON COMENTARIOS SIGNIFICATIVOS!

• Como equipo: mantenga una rama de Desarrollo, luego mueva el código de prelanzamiento (para QA) a una rama de Producción. Esta rama solo debe tener un código completamente funcional.

El Manual TortoiseSVN TSVN se basa en el libro de subversión , pero está disponible en muchos más idiomas.

Creo que hay dos formas de cometer frecuencia:

1. Comprometerse muy a menudo, para cada método implementado, una pequeña parte del código, etc.
2. Confirme solo partes completas de código, como módulos, etc.

Prefiero el primero, porque usar el sistema de control de código fuente es muy útil no solo para el proyecto o la empresa, lo primero es útil para el desarrollador. Para mí, la mejor característica es revertir todo el código mientras busca la mejor implementación de tarea asignada.