A continuación una pequeña minireceta sobre cómo crear un pequeño repositorio de subversión en un sistema remoto, donde alojar tus pequeños proyectos de software o webs.
Este sistema te permitirá tener siempre online una copia actualizada tu código y evitar el tener que llevar .tar.gzs de las últimas versiones de un ordenador a otro. También puede servir como repositorio, en un entorno laboral, de webs, scripts o código de cualquier tipo.
Es tan sencillo como instalar el paquete correspondiente vía apt-get o yum
# apt-get install subversion subversion-tools
# yum install subversion
Ahora debemos optar entre 2 opciones:
1.- Levantamos el daemon de svnserve y creamos un repositorio global en el servidor para todos los usuarios (repositorio por defecto). Esto implica que la gestión de los usuarios se realizará a nivel de servidor (por ejemplo en un fichero de usuarios).
2.- Dejamos que cada usuario aloje sus proyectos en uno o varios repositorios propios en su HOME. Esto sólo necesita acceso SSH abierto en el servidor.
Si vamos a ejecutar subversión sin SSH, directamente contra el servidor svn, necesitaremos un script de parada y arranque y un repositorio por defecto. Creamos el siguiente script:
# cat /etc/init.d/svnserve
#!/bin/sh
#
### BEGIN INIT INFO
# Provides: svnserve
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start:
# Default-Stop:
# X-Interactive: true
# Short-Description: Start/stop svnserve
### END INIT INFO
test -f /usr/bin/svnserve || exit 0
### Podemos cambiar el puerto en el que escuchar:
OPTIONS="-d -r /var/svn/ --listen-port=3690"
case "$1" in
start)
echo -n "Starting subversion daemon:"
echo -n " svnserve"
start-stop-daemon --start --quiet --oknodo --user root --exec /usr/bin/svnserve -- $OPTIONS
echo "."
;;
stop)
echo -n "Stopping subversion daemon:"
echo -n " svnserve"
start-stop-daemon --stop --quiet --oknodo --exec /usr/bin/svnserve
echo "."
;;
reload)
;;
force-reload)
$0 restart
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: /etc/init.d/subversion {start|stop|reload|restart}"
exit 1
;;
esac
exit 0
Damos permisos de ejecución:
# chmod +x /etc/init.d/svnserve
Ahora lo introducimos en el arranque de la máquina:
Debian: # update-rc.d svnserve defaults
CentOS: # ntsysv
También debemos definir y crear el repositorio por defecto para el daemon que corre en memoria, y modificar los permisos de acceso autenticado (auth-access → permitimos escritura), anónimo (anon-access → no permitimos el accesos) y los usuarios/passwords de autenticación en fichero aparte:
# svnadmin create /var/svn/
# egrep -v "^#|^$" /var/svn/conf/svnserve.conf
[general]
auth-access = write
anon-access = none
password-db = passwd
# cat /var/svn/conf/passwd
[users]
miusuario = elpassword
Como luego veremos, nada impide que vía SSH cada usuario pueda tener sus propios repositorios adicionales.
Finalmente, arrancamos el servicio SVN:
# /etc/init.d/svnserve start
En algunos tutoriales se aconseja crear los siguientes directorios base:
# svn mkdir file:///var/svn/trunk -m "Crear trunk"
# svn mkdir file:///var/svn/tags -m "Crear tags"
# svn mkdir file:///var/svn/branches -m "Crear branches"
La ventaja de este sistema es que podemos dar acceso a múltiples usuarios gracias al fichero de passwords, así como dar acceso anónimo de sólo lectura.
Podemos utilizar SVN por SSH si queremos un acceso “personal” a un repositorio a través de nuestra cuenta de trabajo de un servidor o host Linux sin necesitar acceso administrativo (siempre y cuando tenga instalado el paquete de subversion). Normalmente es la forma más utilizada para usuarios individuales (no trabajo en grupo) que quieren guardar sus proyectos o ficheros en un repositorio para evitar el traspaso de ficheros entre diferentes equipos de trabajo (ejemplo: tener la misma copia de código en casa o en el trabajo).
En el caso de utilizar SVN por ssh, no necesitamos arrancar el daemon ni crear este repositorio por defecto. En ese caso, crearemos uno o varios repositorios para nuestro usuario, ubicado donde queramos en el PATH, por ejemplo en /home/usuario/svn:
Si necesitamos acceso de múltiples usuarios vía SSH, lo mejor es crear un usuario común (no nuestro usuario personal) que alojará el/los repositorios.
En el caso de SVN+SSH se nos presentan 2 opciones relativas a la organización de los repositorios:
1.- Crear un único repositorio del que colgarán todos los proyectos:
Creamos un directorio único en el servidor (por ejemplo /home/usuario/svn), creado con “svnadmin create”, el cual alojará todos los proyectos. La raíz del repositorio será dicho directorio, para todos los proyectos. La ventaja de este sistema es la simplicidad del “setup”.
La desventaja de este sistema es que las revisiones del repositorio son comunes a todos los proyectos; es decir, si en un repositorio con 3 proyectos hacemos commit en cada proyecto, la revisión aumenta en 3, no es específica para cada proyecto.
Además, borrar un proyecto es “complicado”: implica regenerar el repositorio a partir de un dump con filtro extraído con “svndumpfilter exclude” (ver reposadmin.maint.filtering).
2.- Crear múltiples repositorios (un repositorio para cada proyecto):
Creamos un directorio único en el servidor (por ejemplo /home/usuario/svn), y dentro de dicho directorio creamos un repositorio para cada proyecto (con “svnadmin create nombreproyecto”). La raíz del repositorio ya no será /home/usuario/svn sino /home/usuario/svn/PROYECTO, según el proyecto con el que queramos trabajar.
La ventaja de este sistema es que cada proyecto tiene su propio sistema de revisiones, y sus propios tags y branches. También, el borrado de los proyectos (repositorios) es muy fácil y simple.
Yo personalmente me decanto por esta opción aunque veremos las 2.
La opción elegida sólo cambia la forma de CREAR EL REPOSITORIO y de hacer LA SUBIDA INICIAL DEL PROYECTO y la DESCARGA INICIAL DEL PROYECTO (digamos que los primeros 10 minutos de uso del repositorio). Después, el uso diario y regular de SVN es igual en ambas opciones.
Creamos el repositorio en el servidor:
$ mkdir /home/usuario/svn/
$ svnadmin create /home/usuario/svn
Una vez hecho esto, vía SSH podemos ya acceder al repositorio referenciándolo como:
$ export SVNROOT="svn+ssh://usuario@server.com/home/usuario/svn/"
De nuevo, se recomienda crear los siguientes subdirectorios:
$ svn mkdir file:///home/usuario/svn/trunk -m "Crear trunk"
$ svn mkdir file:///home/usuario/svn/tags -m "Crear tags"
$ svn mkdir file:///home/usuario/svn/branches -m "Crear branches"
Sea un directorio de código fuente denominado “miproyecto”. Nos situamos en el directorio padre de “miproyecto” y ejecutamos uno de los siguientes comandos:
$ svn import miproyecto svn://server.sromero.org/var/svn/miproyecto
$ svn import miproyecto svn+ssh://server.sromero.org/home/sromero/svn/miproyecto
$ svn import miproyecto ${SVNROOT}/miproyecto
$ svn import miproyecto ${SVNROOT}/miproyecto -m "Upload inicial del proyecto"
Al comando le decimos que importe un directorio específico (svn import miproyecto) y le decimos que lo haga sobre el SVNROOT añadiendo además el subdirectorio del repositorio que alojará el proyecto (miproyecto también en este caso). Esto permite tener múltiples proyectos en cada repositorio, gracias a este path “final” sobre el SVNROOT.
Se nos solicitará entonces la introducción de una línea de texto para “resumir” en qué consiste el cambio realizado. Todos los cambios en el repositorio tienen que tener este “summary” que luego podemos recuperar con “log”.
Como se puede ver en el último ejemplo, podemos agregar el resumen para el log en la línea de comandos (en modo no interactivo) con -m “Upload inicial del proyecto”.
Una vez un repositorio está en un proyecto, podemos “descargar” una copia ya controlada por SVN. De hecho, deberíamos desechar (de momento renombrar) el directorio de proyecto original y trabajar con la copia versionada.
Nos situamos en el directorio de trabajo “padre” y (una vez renombrado el directorio original si existe) ejecutamos lo siguiente (una u otra opción según si tenemos definida o no la variable):
$ svn checkout svn://server.sromero.org/var/svn/miproyecto
$ svn checkout ${SVNROOT}/miproyecto
Esto descargará el proyecto “SVNROOT/miproyecto” recreando el directorio “miproyecto” en el directorio actual.
Esta puede ser la opción más habitual si no queremos mezclar revisiones y si queremos poder borrar un proyecto concreto.
Empezamos creando el directorio común en el servidor SVN:
$ mkdir /home/usuario/svn/
Para cada proyecto a alojar hay después que crear su repositorio en el servidor SVN:
$ svnadmin create /home/usuario/svn/proyecto1
$ svnadmin create /home/usuario/svn/proyecto2
Supongamos que tenemos en nuestro sistema 2 proyectos bajo /home/usuario/code y queremos alojarlos en el servidor de SVN.
Primero preparamos el proyecto1, creando los 3 subdirectorios trunk, branches y tags:
$ cd /home/usuario/code/
$ cd proyecto1
$ mkdir trunk
$ mv * trunk
$ mkdir branches
$ mkdir tags
Una vez estructurado el directorio del proyecto, lo subimos al repositorio:
$ export SVNROOT="svn+ssh://server.sromero.org/home/sromero/svn/proyecto1"
$ svn import proyecto1 ${SVNROOT}/ -m "Agregamos proyecto1 a su propio repositorio"
Nótese que ahora el SVNROOT incluye el subdirectorio “proyecto1”, al contrario que en el caso de múltiples proyectos en un único repositorio.
Repetimos a continuación el proceso para nuestro segundo proyecto:
$ cd /home/usuario/code/
$ cd proyecto2
$ mkdir trunk
$ mv * trunk
$ mkdir branches
$ mkdir tags
$ export SVNROOT="svn+ssh://server.sromero.org/home/sromero/svn/proyecto2"
$ svn import proyecto1 ${SVNROOT}/ -m "Agregamos proyecto2 a su propio repositorio"
Importamos el proyecto “subversionado”, renombrando el directorio original y haciendo un checkout:
$ cd /home/usuario/code/
$ export SVNROOT="svn+ssh://server.sromero.org/home/sromero/svn/proyecto1"
$ mv proyecto1 proyecto1.orig
$ svn checkout $SVNROOT proyecto1
Y lo mismo para el otro proyecto:
mv proyecto2 proyecto2.orig
svn checkout $SVNROOT proyecto2
Ahora ya podríamos trabajar con normalidad dentro de cualquiera de los 2 proyectos (svn update, svn commit, etc), y cada uno de ellos estará alojado dentro de su propio repositorio sin compartir estructuras de SVN con otros proyectos.
El borrado de un proyecto, se realizará en el servidor con un simple:
$ rm -rf /home/usuario/svn/elproyecto
(sin afectar así al resto de proyectos, y pudiendo volver a generarlo de nuevo con un “svnadmin create” si fuera necesario).
Veamos un pequeño “script” que subirá al repositorio todos los proyectos que tenemos bajo un mismo directorio:
En el servidor SVN:
cd /home/usuario/svn
for PROJECT in proyecto1 proyecto2 proyecto3 proyecto4;
do
svnadmin create $PROJECT
done
En nuestro equipo de trabajo:
cd /home/usuario/prog/code
for PROJECT in proyecto1 proyecto2 proyecto3 proyecto4;
do
export SVNROOT="svn+ssh://user@myserver.org/home/usuario/svn/${PROJECT}/"
cd ${PROJECT}
mkdir trunk
mv * trunk
mkdir tags
mkdir branches
cd ..
svn import $PROJECT ${SVNROOT} -m "Agregamos proyecto al repositorio"
done
Con esto hemos subido los diferentes proyectos al servidor SVN, cada uno en un repositorio diferente bajo la misma ruta.
Ahora tenemos que descargarnos los proyectos “subversionados” para trabajar con ellos en lugar de usar los directorios de código fuente originales (que no contienen el directorio oculto .svn):
cd /home/usuario/prog/code
for PROJECT in proyecto1 proyecto2 proyecto3 proyecto4;
do
# Movemos el directorio original como .orig
if [ -e $PROJECT ]; then mv $PROJECT ${PROJECT}.orig ; fi
export SVNROOT="svn+ssh://user@myserver.org/home/usuario/svn/${PROJECT}/"
svn checkout $SVNROOT $PROJECT
done
Esta operación es la misma que tendremos que realizar en otros equipos (ej: en casa) donde guardemos copia de estos proyectos, para tenerlos versionados y apuntando al repositorio desde este momento.
Un apunte final sobre el comando mv del script importador:
mv * trunk
Este comando no movera archivos ocultos a trunk/ si tu proyecto los tiene. En ese caso, se puede usar:
(shopt -s dotglob; mv -- * ..)
(con los paréntesis)
La referencia del repositorio puede ser svn: o svn+ssh: :
svn://server.sromero.org/var/svn/
svn://server.sromero.org:puerto/var/svn/
Repositorio único: svn+ssh://server.sromero.org/home/usuario/svn/
Múltiples repositorios: svn+ssh://server.sromero.org/home/usuario/svn/nombre_proyecto
Repositorio único: svn+ssh://server.sromero.org/home/usuario/svn/
Repositorio único: svn+ssh://usuario@server.sromero.org/home/usuario/svn/
Múltiples repositorios: svn+ssh://usuario@server.sromero.org/home/usuario/svn/nombre_proyecto
export SVN_SSH="ssh -p 24"
Repositorio único: svn+ssh://usuario@server.sromero.org/home/usuario/svn/
Múltiples repositorios: svn+ssh://usuario@server.sromero.org/home/usuario/svn/nombre_proyecto
En ocasiones puede ser útil declarar este valor en un “export SVNROOT” para usarlo después en las llamadas a svn.
SVN/SSH no nos pedirá password si utilizamos autenticación sin password por clave pública/privada. En el caso de SSH, en ocasiones se crea un usuario específico “svn” para que sea dueño específico del repositorio.
Cuando hacemos cambios en el código, debemos de subirlos al repositorio (hacer un commit de los cambios). Hay quien hace commit cada vez que hace un cambio acotado (para que gracias al comentario del commit podamos saber qué cambios se realizan cada vez), y hay quien hace un commit al final de largas sesiones de trabajo.
Una vez hayamos decidido hacer el commit, y estando dentro del directorio de trabajo del proyecto, ejecutamos:
$ svn commit
$ svn commit fichero_o_directorio
$ svn commit -m "Resumen de cambios"
Nótese que no necesitamos especificar el SVNROOT porque viene ya “pregrabado” en el directorio que hemos descargado (directorio oculto .svn).
Si otros compañeros han subido cambios o bien queremos descargar en casa los cambios realizados en el trabajo, podemos hacer un update sobre nuestra copia local (que en algún momento fue descargada con checkout).
$ svn update
$ svn update fichero_o_directorio
En SVN tenemos que “añadir” al repositorio los ficheros NUEVOS que creemos localmente, para que sean también subidos/descargados con los checkouts/updates. También hay que eliminar ficheros remotamente si queremos borrarlos localmente.
$ svn add fichero_o_directorio
$ svn mkdir nuevo-dir
$ svn move file_dir1 file_dir2
$ svn delete fichero_o_directorio
Si hemos hecho cambios en nuestra copia local “descargada”; podemos ver un diff de dichos cambios con:
$ svn diff
$ svn diff fichero_o_directorio
$ svn diff | less
$ svn diff | vim -
Es posible en algún momento que hayamos hecho cambios en algún fichero de nuestra copia local y queramos deshacerlos para empezar de cero con los datos que hay en el repositorio. En ese caso no es necesario realizar un checkout de nuevo, podemos hacer un:
$ svn revert fichero_o_directorio
O bien, si queremos revertir todos los cambios (.) o los de un directorio:
$ svn revert --recursive .
$ svn revert --recursive directorio
Lo siguiente muestra todo el registro de cambios de un proyecto:
$ svn log
$ svn log fichero_o_directorio
El siguiente comando proporciona un listado de nuevos ficheros, ficheros modificados, y ficheros a borrar en el próximo commit.
$ svn status
Resulta también muy útil para conocer si en el directorio actual hay ficheros sin versionar (a los que falta hacerle el svn add), porque estos aparecen con el prefijo ?:
$ touch new_file
$ svn status
? new_file
Si no estamos usando svn+ssh, puede ser interesante especificar user/pass en línea de comandos:
--username sromero --password XXXXXX
También, para el checkout y para el update, puede ser útil la opción –force.
Con –force podríamos hacer un checkout de un proyecto recién subido al repositorio con un import sobre el directorio “inicial” sin renombrarlo. Es decir, podríamos subir una web al repositorio y hacer un checkout –force en el directorio de la web para “descargar la copia remota” y crear las estructuras .svn sin tener que renombrar el directorio y hacer el checkout (que cortaría la web mientras hacemos el mv + checkout).
Para mover un repositorio se puede usar switch:
$ svn switch --relocate old-url new-url
En subversion tenemos disponibles las siguientes funcionalidades:
Para crear un tag o un branch, lo haríamos con el comando “svn copy”
$ svn copy trunk tags/0.1.0 -m "Version 0.1.0 del proyecto"
$ svn commit -m "Version 0.1.0" tags/
$ svn copy trunk tags/0.1.0-antes-de-probar-SDL -m "Snapshot antes de probar SDL"
$ svn commit -m "Snapshot antes de probar SDL" tags/
$ svn copy trunk branches/soporte-android -m "Creamos branch pruebas Android"
$ svn commit -m "Branch pruebas de soporte para Android" branches/
También podemos crear un tag o branch no desde la rama de trunk sino desde nuestra copia local (directorio del proyecto), es decir, con cambios aún no subidos al repositorio:
$ svn copy miproyecto ${SVNROOT}/tags/android-funcional -m "Tag con codigo Android Funcional"Para borrar un tag o un branch, lo haríamos con “svn delete”:
$ svn delete tags/0.1.0-antes-de-probar-SDL -m "Eliminamos el tag: SDL implementado OK"
$ svn commit -m "Borrado tag 0.1.0-antes-de-probar-SDL"
$ svn delete branches/soporte-android
$ svn commit -m "Se borra la rama de soporte para Android"
En realidad, físicamente no se borra el código, sólo se marca el repositorio de forma que ya no “exista” en cuanto a actualizaciones. No obstante, podemos recuperar cualquier número de revisión en cualquier momento con:
$ svn copy ${SVNROOT}/branches/rama-android@15 \
${SVNROOT}/branches/rama-android \
-m "Restaurando revision 15"Podemos obtener un listado de tags o branches del proyecto con svn list (para restaurar revisiones puede sernos útil también svn log, svn info y svn status).
$ svn list ${SVNROOT}/tags
0.1.0/Y podemos hacer un checkout de un release concreto con:
$ svn checkout ${SVNROOT}/tags/0.1.0 Una de las pegas de los tags es que son parte del proyecto por lo que cada vez que hagamos checkouts o updates nos los vamos a descargar en ~/proyecto/tags . Si queremos evitar esto, podemos hacer checkout sólo del raíz del repositorio (no recursivamente, -N) y actualizar sólo el trunk:
$ svn checkout $SVNROOT -N PROYECTO
$ svn update PROYECTO/trunk
De esta forma sólo descargamos el trunk, y no tags ni branches, por lo que no desperdiciamos espacio en disco local.
Existen diferentes políticas al respecto de cómo trabajar con el código y las ramas.
Quizá la más extendida es trabajar sobre la rama principal (trunk) y cada cierto tiempo crear una rama denominada “estable”. El proyecto se continúa después sobre la rama principal y la estable sólo se modificará (durante el tiempo de vida de dicha versión) para corregir bugs (que también se deberán corregir en el trunk si le afectan); las nuevas características o funcionalidades sólo se implementarán en la rama principal.
Así, podemos crear una nueva rama y trabajar sólo sobre ella así:
$ svn info ${SVNROOT}/trunk | grep Revision
# (anotamos el numero de revision actual "REVISION_ACTUAL")
$ svn copy ${SVNROOT}/trunk ${SVNROOT}/branches/stable-1.0 \
-m "Rama estable LA_REVISION_ACTUAL"Ahora configuramos nuestra copia local como la nueva rama:
svn switch --relocate ${SVNROOT}/trunk ${SVNROOT}/branches/stable-1.0En este momento, podemos trabajar con nuestra copia local y ya no estaremos trabajando con el trunk sino con “stable-1.0”.
$ svn info | grep URL
$ svn update
# (hacemos cambios)
$ svn commit -m "Bug corregido en blah"
Estos pasos servirán incluso si tenemos cambios en nuestra copia local que todavía no hemos subido al trunk, porque hemos decidido que estén en la nueva rama y no en el trunk.
Convertir nuestra rama en la rama principal
También podemos haber querido crear una rama para explorar una alternativa al código (por ejemplo, cambiar de GTK a QT) y que los cambios hayan tenido éxito y queramos convertir esta rama en la versión principal:
Un primer método es borrar el trunk y convertir el código de nuestra rama en el trunk:
$ svn delete ${SVNSERVER}/trunk
$ svn move ${SVNSERVER}/branches/programa-con-qt ${SNVSERVER}/trunk
$ svn switch --relocate ${SVNSERVER}/branches/programa-con-qt ${SVNSERVER}/trunk
Hacer merge de los cambios de nuestra rama con la principal
El merge de una rama al trunk se realiza con:
$ svn merge -r XXX:YYY $SVNROOT/branches/la-rama
$ svn commit -m "Realizado merge de la-rama (XXX:YYY) al trunk"
Siendo XXX la revisión en la cual nació la rama y YYY la revisión actual del trunk.
Para obtener estos datos, podemos:
# hacer un checkout del trunk y de la rama en otro directorio:
$ cd ..
$ mkdir temp
$ cd temp
$ svn checkout $SVNSERVER/trunk trunk
$ svn checkout $SVNSERVER/branches/la-rama la-rama
$ cd la-rama
# encontrar la revisión donde se creó la rama (XXX):
$ cd la-rama
$ svn log --stop-on-copy
# encontrar la revisión actual del trunk ("At revision YYY"):
$ cd ..
$ cd trunk
$ svn update
Esto realizará un merge del código de la-rama sobre el trunk. Si hubiera conflictos de edición de ficheros (puede haberlos), los arreglamos localmente y hacemos un commit para subirlos:
$ vim fichero_que_da_conflictos.c
$ svn commit -m "Merge de
$ svn commit -m "Realizado merge de la-rama (XXX:YYY) al trunk"
Simplemente, ejecutampos lo siguiente en el repositorio:
# TODO EL ARBOL DE PROYECTOS/REPOSITORIOS
$ rm -rf /home/sromero/svn/
# UN REPOSITORIO CONCRETO:
$ rm -rf /home/sromero/svn/PROYECTO/
Para volver a tenerlo operativo habría que seguir de nuevo el proceso de creación (mkdir, svnadmin create, editar conf/svnserve.conf, e importar en él proyectos).
Según si vamos a crear un repositorio común para todos los proyectos, o si vamos a crear un repositorio por cada proyecto, los comandos exactos son ligeramente diferentes (ver las correspondientes secciones al principio de este documento), pero generalizando, son:
1.- Crear el/los repositorios en el servidor.
2.- Establecer variables de entorno (SVNROOT y SVN_SSH si necesitamos cambiar el puerto).
3.- Preparar los directorios de nuestro proyecto (en el caso de múltiples repositorios, crear directorios trunk/branches/tags).
4.- Subir nuestro proyecto o web al repositorio.
5.- Renombrar el directorio antiguo.
6.- Descargar el mismo directorio pero con el control de versiones.
7.- Revisar que la descarga es correcta y que no faltan ficheros.
8.- “Archivar” (guardar, borrar) el directorio de código antiguo.
A partir de ahora, debemos trabajar sobre el directorio de trabajo creado acordándonos de realizar “svn add” de nuevos ficheros, “svn delete” de ficheros que borremos, y de hacer los commits para subir nuestro trabajo y updates para recuperar el trabajo de los demás.
Una cosa habitual para las personas que trabajamos con varios PCs (portátil, sobremesa casa, trabajo…) es tener gran cantidad de ficheros de configuración comunes entre todos ellos: .vimrc, .bashrc, .tmux.conf, así como directorios de notas, documentación, etc… En esos casos, cada vez que hacemos una mejora en uno de los ficheros, tenemos que distribuirlo manualmente a los otros equipos (vía correo, scp, o llavero USB).
En este ejemplo, vamos a mantener una copia selectiva de ficheros de nuestro HOME en un repositorio privado online de subversion, de forma que con un simple svn update (incluso podría ser automatizado en el login de nuestro usuario) podamos actualizar nuestro HOME local con las últimas copias de dichos ficheros. No sólo eso, sino que nos protege contra borrados accidentales de ficheros (podemos recuperarlos con un svn update) o para encontrar cambios en los ficheros que hayan producido algún problema (volviendo a revisiones anteriores, etc).
NOTA: nunca debemos subir ficheros con datos sensibles en cualquier caso, como una clave SSH, si no confiamos en la seguridad de dicho servidor.
Por ejemplo: estamos en el trabajo, encontramos una opción fantástica para el fichero .vimrc, la añadimos, hacemos un svn commit -m “Nueva opcion vimrc”, y luego en casa sólo hay que hacer svn update (o bien, como he dicho, ponerlo de forma automática en el arranque o el login del usuario).
Para montar este sistema, primero creamos el repositorio en el servidor:
$ svnadmin create /home/usuario/svn/home
Ahora ya en la parte cliente, creamos un directorio “home” ficticio, vacío, para subirlo al repositorio:
$ cd
$ mkdir home
$ export SVNROOT="svn+ssh://usuario@server.org/home/usuario/svn/home"
$ svn import home $SVNROOT -m "Creado homedir"
$ rm -rf ~/home
Finalmente, dentro de nuestro /home/usuario real, hacemos un checkout de “home” para que svn cree un directorio .svn de control en nuestro home.
$ cd /home/usuario
$ export SVNROOT="svn+ssh://usuario@server.org/home/usuario/svn/home"
$ svn checkout $SVNROOT . --force
Revisión obtenida: 0
Este checkout lo tenemos que realizar inicialmente en todos lo /home/usuario de los equipos donde queremos tener sincronizados los ficheros (por ejemplo, casa, trabajo, portátil)…
Ojo, –force sobreescribirá cualquier archivo ya existente, por lo que hay que revisar que no hayamos subido al SVN ninguno que no queramos tener idéntico entre los diferentes equipos (en cualquier caso, se recomienda hacer una copia previa a otro directorio “old” de los ficheros que se sobreescribirán la primera vez, por si acaso).
Desde este momento ya podemos subir ficheros a nuestro repositorio:
$ svn add .vimrc* .tmux.conf .gvimrc
A .vimrc
A .vimrc.common
A .tmux.conf
A .gvimrc
$ svn commit -m "Subidos ficheros iniciales"
Añadiendo .gvimrc
Añadiendo .tmux.conf
Añadiendo .vimrc
Añadiendo .vimrc.common
Transmitiendo contenido de archivos ..........
Commit de la revisión 1.
Con esto, cada vez que añadamos alguna funcionalidad nueva en el .vimrc, por ejemplo, en casa, podemos hacer un update en el trabajo y disfrutar de “contenidos sincronizados” sin andar enviando ficheros por correo o en unidades USB.
Simplemente tenemos que hacer un svn update en cada sitio para tener regularmente sincronizados los ficheros que tengamos en el repositorio.
# En otro sistema diferente,
$ export SVNROOT="svn+ssh://sromero@server.sromero.org/home/sromero/svn/home"
$ svn update --force
Además de ficheros podemos añadir directorios completos con sus subdirectorios:
$ svn add docs
A docs/notas_subversion.txt
A docs/comandos_utiles.txt
A docs/tutorial_truecrypt.txt
(...)
$ svn commit -m "Subido directorio docs"
Si queremos añadir sólo algunos ficheros de un directorio (es decir, ficheros selectivamente, pero no todo el contenido), bastará con que agreguemos el directorio con –non-recursive y luego los ficheros individuales. Esto puede ser útil por ejemplo si tenemos un directorio que tiene algún fichero que DEBE de ser diferente en ambos sistemas:
$ ls -1 bin
haz_backup.sh
sistema_backup.py
wxmylauncher.py
$ svn add bin --non-recursive
A bin
$ svn add bin/sistema_backup.py bin/wxmylauncher.py
A bin/sistema_backup.py
A bin/wxmylauncher.py
$ svn commit -m "Subidos algunos ficheros de bin/"
De esta forma, los updates sólo actualizarán los 2 scripts que hemos marcado, y podemos tener así scripts con el mismo nombre pero distinto contenido en las diferentes máquinas.
Podemos habilitar un script para facilitarnos el “svn update” del home:
$ cat bin/update_home_svn.sh
#!/bin/bash
# Update home directory from SVN
export SVNROOT="svn+ssh://usuario@server.org/home/usuario/svn/home"
cd $HOME
svn update
Siendo este script otro candidato a mantener en SVN (svn add bin/update_home_svn.sh + svn commit).
Permite a varios autores editar simultáneamente un documento de texto, y ver todos los participantes en las ediciones en tiempo real, con la capacidad de mostrar el texto de cada autor en diferente color. También hay una ventana de chat en la barra lateral para permitir la comunicación directa.
Este antiguo servidor Web está ganando popularidad dentro del ámbito empresarial. NGINX es ahora el nuevo número dos de servidores Web, en gran parte porque es una alternativa rápida, ligera y de código abierto al todopoderoso Apache. He aquí el por qué atrae tanto la atención.
http://blog.desdelinux.net/nginx-una-interesante-alternativa-a-apache/
iconv is a computer program and a standardized application programming interface (API) used to convert between different character encodings.
http://en.wikipedia.org/wiki/Iconv
py2Nsis is a Simple to Use, Nsis installers generator for python projects. It also make the setup.py for py2exe.
Nsis is a professional open source system to create Windows installers.
py2exe is a Python Distutils extension which converts Python scripts into executable Windows programs, able to run without requiring a Python installation.
py2Nsis combines the capabilities of these ones and generates directly a Windows installer with just a few information about your python code!
We offer a boot disk for everything from MS-DOS 3.3 to Windows XP Professional. These disks can be used to setup a new hard drive, scan an existing hard drive for errors, install or re-install Windows, upgrade your PC's BIOS, run DOS utilities and much more.
