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.

1. Buenas prácticas
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.

12. Buenas prácticas (4/8)

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.

17. SUBVERSION
Buenas Prácticas
FIN
Iker Canarias
iker.canarias (gmail)