GUIA PARA EL USO DEL SERVIDOR SVN

Subversion (SVN) 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
órdenes.
Una característica importante de Subversion es que, a diferencia de CVS, los archivos
versionados no tienen cada uno un número de revisión independiente, en cambio, todo el
repositorio tiene un único número de versión que identifica un estado común de todos los
archivos del repositorio en un instante determinado.
Subversion puede acceder al repositorio a través de redes, lo que le permite ser usado
por personas que se encuentran en distintas computadoras. A cierto nivel, la posibilidad de
que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus
respectivas ubicaciones fomenta la colaboración. Se puede progresar más rápidamente sin
un único conducto por el cual deban pasar todas las modificaciones. Y puesto que el trabajo
se encuentra bajo el control de versiones, no hay razón para temer por que la calidad del
mismo vaya a verse afectada —si se ha hecho un cambio incorrecto a los datos,
simplemente deshaga ese cambio.

Integración con Aptana

1. Instalar el plugin para svn, subversive:

• En MyStudio -> Install Plugins -> Utilities -> Subversive (Get it) .
• Seleccione las entradas: Subversive Integration Plug-in's (Incubation),
Subversive sources (Incubation), Subversive SVN Team Provider Plugin
(Incubation).
• Una vez instalado seguir la recomendación de reiniciar Aptana
• Al reiniciar se debe abrir perspectiva para svn (Windows -> Open perspective ->
Other -> SVN Repository Exploring) se mostrará entonces un diálogo para
instalar los conectores, seleccione según la versión de java que tenga instalado
y en uso (si desea conocer la versión actual escriba en consola update-java-
alternatives -l); si tiene la versión 1.5 escoja: SVN Kit 1.2.3 y JavaHL 1.5.x, en
caso de que tenga la versión 1.6 de java seleccione: SVN Kit 1.3.5 y JavaHL
1.6.x.
• Se vuelve a seguir la recomendación de reiniciar Aptana.

Otra opción para su instalación se encuentra en

http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/install.php

2. Configuración .

• En el área "SVN Repositories" o "SVN Repositories Browser" desplegar el menú

contextual y seleccionar New -> Repository Location; esto abrirá una nueva
ventana cuyos datos contendrán:
 ◦ General
▪ URL: ->
svn+ssh://direccion_ip/home/repositorio_svn/nombre_proyecto/tr
unk
▪ Authentication
• User: nombre_usuario
• Password: nombre_usuario
◦ Advanced, desmarcar "Enable structure Detection".
◦ El resto de los datos no se modifica.

Al finalizar se abrirá la opción de almacenar la contraseña (Secure Storage), allí puede

crear una contraseña para el almacenamiento seguro de las contraseñas de forma
encriptada.

3. Crear proyecto

Al crear el proyecto se descargan los archivos alojados en el servidor (check out).

• File -> New -> Project

• En el wizard seleccionar SVN -> Project from SVN -> Use existing repository
location
svn+ssh://direccion_ip/home/repositorio_svn/nombre_proyecto/trunk ->
Finish
• Check out as a project configured using the New Project wizard -> Finish ->
General -> Project -> Project name -> Finish.

4. Cómo subir los archivos modificados al servidor.

• Sobre el proyecto despliegue el menú contextual y seleccione Team -> Commit .

RECUERDEN NO SUBIR EL ARCHIVO CORRESPONDIENTE AL PROYECTO

DE APTANA (.project)

Sin Aptana

1. Instalar el cliente svn para navegar por el repositorio, subir y descargar los archivos.
Opciones:
• RabbitVCS (http://wiki.rabbitvcs.org/wiki/install/ubuntu)
• KDEsvn
• rapidSVN

2. Obtener la versión actual del repositorio .

En consola escribir:

$cd /var/www/
 $mkdir nombre_proyecto
$svn checkout
svn+ssh://nombre_usuario@direccion_ip/home/repositorio_svn/nombre_proyecto/
trunk/ nombre_proyecto

3. Subir los archivos modificados al servidor .

$svn --username nombre_usuario commit -m "Documentacion"

RECOMENDACIONES GENERALES

• Antes de hacer cualquier modificación en su entorno local, los desarrolladores deben

asegurarse de estar trabajando con la última versión del software del repositorio. Lo
mismo sucederá al finalizar un desarrollo: antes de persistir los cambios en el
repositorio de Subversion se deberá asegurar que no se está interfiriendo con un
desarrollo paralelo que ya haya sido guardado en el repositorio. Para esto se utilizará
el mecanismo de sincronización de Subversion.
Existen tres formas de sincronizar el código del entorno local con el del repositorio:
◦ El comando Checkout descargará al entorno local una copia fiel del código del
repositorio. Útil para comenzar a desarrollar sobre proyectos nuevos.
◦ El comando Update descargará al entorno local únicamente las modificaciones que
hayan tenido lugar desde la última sincronización. Sólo se podrá hacer esta
operación si se dispone ya de una versión local del código del repositorio.
◦ El comando Commit actualizará el contenido del repositorio con los cambios del
entorno local. Subversion sólo permitirá esta operación si no existen conflictos con
el código ya existente en el repositorio. Es decir, no permitirá hacer Commit si otro
miembro del equipo ha modificado el mismo elemento de forma paralela desde la
última sincronización de código.
La dinámica habitual de trabajo deberá ser la siguiente:
1. Antes de comenzar con la resolución de una tarea, se deberá asegurar la
sincronización con el repositorio, bien con un Update o bien con un Checkout
dependiendo de si se dispone previamente del código en el entorno local o no.
2. Una vez resuelta la tarea, se deberá hacer otro Update para traer al entorno
local los cambios que hayan podido ser realizados en paralelo al desarrollo
actual. Subversion sabrá integrar los cambios del repositorio con los del entorno
local en la mayoría de los casos, pero existirán situaciones que requieran de
intervención humana para la integración. Estos casos, se deberán resolver de
forma manual procurando mantener las modificaciones propias y las realizadas
por los otros desarrolladores en paralelo.
3. Finalmente se deberá hacer el Commit para hacer público al resto del equipo el
código desarrollado. El alcance del Commit deberá limitarse al código relevante
a la resolución de la tarea, y no mezclar desarrollos de distintas tareas en un
 mismo Commit.
• Lo ideal es subir los archivos agrupados por modificación.
• Recuerden que la documentación es muy importante, se debe mencionar el error que
se corrige o la modificación que se implementa; si se modifican varios puntos a la vez
(p.e. cuando estén relacionados) indicar los archivos (con la ruta completa a partir de
la carpeta del proyecto) que corresponden a cada uno (y si es posible las líneas).
• Es buena práctica crear un formato común o estándar para la documentación, como
por ejemplo:
Fecha
Nombre
Modificacion
Archivos afectados