Send to Friend

Entrada de blog from UDT%message %body

Subversion vs CVS. Guía rápida de Subversion (SVN)

CVS y Subversion (SVN) sirven para controlar las versiones y la historia de los proyectos software. Por lo tanto, a grandes rasgos, permiten:
  • que varias personas puedan trabajar en un mismo proyecto sin afectarse mutuamente en el trabajo que realiza,
  • que haya un histórico de revisiones, por seguridad y para poder recuperar una versión anterior de nuestro código,
  • gestionar versiones de la aplicación, derivaciones y demás.

Podríamos decir que las instancias de CVS y Subversion son repositorios, es decir, un almacén de ficheros, sus versiones y su historial de cambios.

 

Comparativa

Subversion es evolución natural de CVS, mejorando algunas de las carencias de este último. Veamos una comparación:

CVS

Subversion (SVS)

Licencia gratuita

Licencia gratuita

Multiplataforma

Multiplataforma

Orientado a ficheros

Versiona los ficheros,
no el proyecto. Esto quiere decir que cada modificación en cada fichero hace
variar  la versión del fichero
modificado.

Orientado a proyectos

Versiona los proyectos, no los ficheros. Es
unaopción mucho más intuitiva que no la de versionar ficheros.

 

Envía ficheros completos

Cuando se hace una modificación
en un fichero, se sube al repositorio el fichero entero, en vez de sólo los
cambios.

Envía sólo cambios

Cuando se hace una modificación en un fichero, se
sube al repositorio el cambio realizado, no el fichero entero. Más eficiencia.

Soporte Unicode limitado

Puede traer problemas
con caracteres "raros".

Soporte Unicode

En principio no debería dar problemas de esta
índole. En principio.

Renombrar/eliminar

No da soporte. Hay que
hacerlo manualmente: copiar con otro nombre y borrar el antiguo.

Renombrar/eliminar

Da soporte parcial. El usuario lo hace en una
única operación pero SVN internamente lo hace las dos cosas en una transacción
de forma transparente al usuario: copiar con otro nombre y borrar el antiguo.

 

Funcionamiento de Subversion

  • Update: Puede haber conflicto entre nuestra copia local del proyecto y la versión en SVN. En tal caso hay que resolver conflictos con merge. Existe una herramienta gráfica de resolución de conflictos que da al programador la oportunidad de escoger entre tres posibles contenidos del fichero:
    • contenido en SVN,
    • contenido en HD local del programador,
    • contenido fusionado por SVN.
  • Edición: El programador modifica los ficheros del proyecto.
  • Commit:  No existe conflicto ya que o nos dejan subir o no nos dejan subir. Los commits son atómicos. O suben todos los ficheros o no sube ninguno (similar a las transacciones con BD) Si no podemos subir un proyecto hay que hacer un update y resolver conflictos. El número de revisión del proyecto se incrementa independientemente de donde se realice el commit (en la rama principal o en una subrama). Todos los commits deberían estar comentados.

SVN de alguna forma penaliza al último en subir los cambios


Ejemplos de trabajo con subversion

Obtenemos una instancia del repositorio en nuestra máquina de trabajo:

svn checkout svn://server/poject

Esto nos copiará los archivos del repositorio, y en cada carpeta añadirá un directorio
oculto de nombre .svn en donde guarda los metadatos con el historial de cambios, las
distintas versiones y demás.
Una vez tengamos la copia en nuestra máquina, el proceso a seguir para a la hora de
realizar modificaciones es:

  1. svn update, para actualizar nuestra versión, por si algún compañero ha introducido algún cambio,
  2. modificamos los ficheros que tengamos que modificar, por ejemplo el fichero carpeta/index.html,
  3. cuando hayamos terminado deberíamos volver a hacer un svn update, por si alguien ha modificado también el mismo fichero que nosotros,
  4. svn commit -m "esto es lo que he hecho" carpeta/index.html para commitear o subir al respositorio la modificación que hayamos realizado, indicando una breve descripción de la misma.

Más información

Página oficial del proyecto [english]