¿Es realmente necesario versionar el código? Análisis SVN

La respuesta es simple y tajante: SI, SIEMPRE. Voy a explicar en el artículo cuales son las ventajas de usar un sistema de control de versiones y cuales son los típicos errores que solventamos con estas herramientas. En este caso hablaré de SVN a modo de ejemplo (no soy ni fanboy de SVN ni hater de Git — sí, hay sectas –).

¿Cuál utilizar?

Esto realmente es como los colores, depende del gusto de cada uno. Hoy en día los más utilizados son SVN y Git pero irán apareciendo muchos diferentes e irán muriendo antiguos. Se pueden escribir muchos artículos sobre cada sistema, pero lo realmente importante es elegir uno que esté extendido en la comunidad.

¿Qué ventajas tiene?

Quizás el tema sea mejor tratar desde otro enfoque: “cuales son las desventajas de no usar un VCS” pero principalmente estas son las ventajas:

Poder trabajar en equipo sin gritar “estoy tocando el index.php!”

Si estás trabajando en equipo es prácticamente obligatorio utilizarlo. El VCS se encargará de que nadie pise el trabajo de otro. Utilizar un sistema de versiones agilizará el trabajo y aumentará el desarrollo en un 50%. Lo hace aplicando 2 principios: Commit y Update.

Antes de comenzar a trabajar es recomendable hacer un Update (actualizar) para traer los cambios que hayan hecho los compañeros y estar al día con el código.

//ir a la ruta del proyecto
$ cd /ruta/a/proyecto
//realizar un Update del proyecto
$ svn up 

Es posible hacer Update en una directorio o un archivo específico.

//actualizar el archivo index.php
$ svn up index.php
//actualizar la carpeta actual
$ svn up

Cuando tienes lista una funcionalidad (y solo si está terminada)  tienes que hacer Commit y agregar un comentario que explique los cambios que has hecho. Al principio es difícil, pero es MUY IMPORTANTE comentar los Commits un compañero de trabajo puede agradecerlo mucho.

//commit del archivo modificado.
$ svn ci index.php -m "Mejora en detección de IP"

Poder responder a la preguntas: “¿Quién tocó aquí?” y “¿Por qué lo tocó?”

Si tienes dudas sobre quién ha tocado un archivo y el motivo, puedes combinar 2 comandos muy útiles:

SVN log

Este comando es para ver las ultimas modificaciones de una carpeta o un archivo

//svn log <archivo/directorio> [-r desde:hasta ]

//ver los ultimos cambios de la carpeta actual
$ svn log 
//ver los ultimos cambios de un archivo
$ svn log classConError.php
//ver los cambios en la revisión 14
$ svn log classConError.php -r 14
//ver los cambios desde la revisión 14 a la última
$ svn log classConError.php -r 14:HEAD
//ver los cambios el 4 de octubre
$ svn log classConError.php -r {2015-10-04}
//ver los cambios desde 4 de octubre al 20 de diciembre
$ svn log classConError.php -r {2016-10-04}:{2015-12-20}

Este comando imprimirá todas las revisiones que afecten a ese archivo o carpeta con su comentario y fecha.

SVN blame

La respuesta a “¿quién demonios ha tocado esto?” nos la da este comando, cuando lo ejecutamos imprime el archivo y línea a línea indica quien lo tocó y en que revisión.

//ver quien toca cada línea de código
$ svn blame classConError.php

Si combinamos los último comandos tenemos control absoluto de lo que está sucediendo en el código.

Olvidarte de juntar tus cambios con los de tu compañero

Utilizando Commit y Update, Subversion va mezclando los archivos siempre que sea posible, por lo que si dos personas tocan el mismo archivo pero en lugares diferentes, el sistema se encarga de hacer el Merge de las versiones. En caso de no poder se crea un conflicto.

Esto sucede al hacer Update: si tienes cambios en un archivo y al hacer update se actualiza este archivo existen dos posibles situaciones:

Merge

Esto significa que Subversion ha juntado tus cambios actuales con los nuevos que has traído en el Update. A continuación, puedes hacer un Commit con tus cambios.

Conflict

Esto significa que Subversion no ha podido juntar los cambios creando un conflicto. El sistema no te permitirá hacer commit hasta que resuelvas el conflicto.

//actualizar proyecto
$ svn up
Updating '.':
D    classBorrada.php
U    classConCambio.php
G    classCambiando.php
C    classCambiandoTambien.php
At revision 330.

Al hacer update se nos hace un resumen de lo sucedido, podemos ver que el primer archivo ha sido borrado (D Deleted), el segundo alguien lo ha cambiado (U Updated), el tercero también lo han tocado y lo ha juntado con mis cambios actuales (M Merged) y el cuarto tiene un conflicto porque no ha podido juntar los cambios de otro con los míos (C Conflict). También se nos muestra en que revisión está el proyecto.

Poder volver atrás: “¿Hace una semana esto funcionaba?”

Para ver cambios anteriores tenemos 2 comandos que hemos de saber combinar

SVN Update

Este comando no solo sirve para actualizar el proyecto, sino que también sirve para actualizarlo a una revisión específica, esto nos ayuda a poder obtener el código que se tenía la semana pasada para hacer pruebas.

//actualizar el proyecto al 4 de octubre
$ svn up -r {2015-10-04}
//actualizar el proyecto a la revisión 300
$ svn up -r 300

SVN Diff

Este comando nos sirve para saber que cambios hay entre una revisión y otra, con esto podemos saber que cambios se han hecho entre 2 revisiones.

//ver cambios en un archivo desde el 4 de octubre
$ svn diff -r {2013-10-04}:HEAD index.php 
===================================================================
--- classConCambio.php	(revision 299)
+++ classConCambio.php	(revision 300)

-$this->obtenerMedia();
+$this->obtenerMax();
===================================================================
--- classConCambio.php	(revision 306)
+++ classConCambio.php	(revision 310)

-$total = (int) $total;
-return $total;
+return (int) $total

Podemos ver que entre la revisión 299 y 300 se ha quitado una linea y se ha reemplazado por otra y también que desde la 306 a 310 se ha cambiado como se hace el casting a int de la respuesta de una función.

No te gusta usar línea de comandos? no importa!

Lo más normal es utilizar SVN desde línea de comandos, pero también existen clientes que nos facilitan la tarea. Más adelante haré un Artículo sobre un buen entorno de desarrollo, pero les adelanto que para trabajar en PHP con Subversion lo mejor que he encontrado es Sublime Text 3 con Package Control y la extensión  SVN.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on StumbleUpon
Pablo Oneto

Soy un desarrollador de software web especializado en PHP.

1 Comments

Deja un comentario