Subversion es un sistema de control de versiones diseñado específicamente para reemplazar al popular CVS. Es software libre bajo una licencia de tipo Apache/BSD y se le conoce también como svn por ser el nombre de la herramienta utilizada en la línea de comando. Esta presentación recoge buenas prácticascon Subversion. Además, se hace una pequeña introducción a las principales características y conceptos básicos de Subversion.
2. Conceptos básicos
¿Qué es Subversion?
¿Qué es un commit?
¿Qué es una rama?
¿Qué es Merge?
3. Conceptos básicos (1/4)
¿Qué es Subversion (SVN)?
Subversion es un software que proporciona un sistema
de control de versiones.
Software libre bajo una licencia de tipo Apache/BSD.
Todo el repositorio tiene un único número de versión que
identifica un estado común de todos los archivos del
repositorio en cierto punto del tiempo.
4. Conceptos básicos (2/4)
¿Qué es un commit?
“Hacer un commit” significa subir (guardar) algún
cambio al repositorio.
Al hacer un commit, se genera un nuevo número de
revisión en el repositorio, el cual se asignará a dicho
commit.
Es obligatorio añadir comentarios a los commits para
poder seguir el progreso de un proyecto.
5. Conceptos básicos (3/4)
¿Qué es una rama?
Directorio del repositorio que contiene código del
proyecto.
Lo habitual es tener 3 ramas:
•Trunk: Es la rama principal de desarrollo.
•Tags: Es la rama de “etiquetas”. (Hitos)
•Branches: Esta rama se utiliza para crear
desarrollos paralelos a la rama de trunk.
(pruebas, desarollos largos, etc.)
6. Conceptos básicos (4/4)
¿Qué es Merge?
La acción de aplicar diferencias entre dos rutas de
trabajo.
Merges entre ramas distintas o entre la misma rama, pero
con diferentes versiones.
Muy útil para descartar cambios que se hayan subido por
error al repositorio, o para incorporar cambios que se haya
desarrollado paralelamente a Trunk.
7. Buenas prácticas
No utilizar SVN como un backup.
Hacer commit por unidad lógica.
Comentarios: obligatorios, precisos y
exhaustivos.
NUNCA ROMPER TRUNK.
Actualizarse los proyectos a menudo.
No subir ficheros de configuración.
Ver el histórico de cambios.
8. Buenas prácticas (1/8)
No utilizar SVN como un backup
Se considera mala práctica hacer commit de todos los
cambios cada día, por el simple hecho, por ejemplo, de que
se acaba la jornada laboral.
El motivo de un commit no es hacer una copia de
seguridad, si no generar una nueva versión estable con
nueva funcionalidad, correcciones, etc. sobre uno o varios
proyectos.
9. Buenas prácticas (2/8)
¿Cada cuanto hacer commit?
No se debe subir cada línea que se programe ni tampoco
después de todo el día trabajando.
Se debe hacer un commit tan pronto como los cambios
conformen una unidad lógica, teniendo en cuenta que
nunca se debe romper la compilación.
No se debe temer remitir pequeños cambios con mucha
frecuencia.
10. Buenas prácticas (3/8)
Comentarios: precisos y exhaustivos
Cada commit debe ir asociado obligatoriamente con un
comentario.
Además, ese comentario deberá ser preciso y exhaustivo.
Esto no quiere decir que haya que poner comentarios muy
largos, si no que éstos deberán ser precisos y explicar qué
es lo que hace ese commit y, en la medida de lo posible,
indicar porqué se ha hecho.
11. Buenas prácticas (4/8)
NUNCA ROMPER Trunk
Descargarse los cambios antes de hacer commit.
Verificar siempre los cambios antes de enviarlos al
repositorio.
Comprobar que se sube todo lo que se tiene que subir, ni
más ni menos, y en todos los proyectos con dependencia.
13. Buenas prácticas (5/8)
Actualizarse los proyectos a menudo
Tener los proyectos lo más actualizado posible.
En Eclipse, conviene usar continuamente la opción de
“Synchronyze with repository” para ver los cambios de
manera gráfica. Se desaconseja usar la acciones de
commit y update sin haber hecho un “Synchronyze with
repository” antes.
Antes de hacer un commit.
14. Buenas prácticas (6/8)
No subir ficheros de configuración
Controlar escrupulosamente los ficheros que se suben a
Subversion.
NUNCA subir ficheros de configuración de Eclipse (u
otros IDEs), como ficheros .classpath, .project, etc.
15. Buenas prácticas (7/8)
Ver el histórico de cambios
Te da una visión sobre lo que está pasando en el
proyecto.
Evita programar código repetido, ya que alguna
funcionalidad resuelta por otro compañero puede ser
reutilizada por nosotros.
16. Buenas prácticas (8/8)
Hacer REVERT, no deshacer a mano
No deshacer a mano cambios hechos por error.
Más fiable que hacerlo a mano.
No hay que hacer un commit, la versión continúa como
estaba.