Showing posts with label svn. Show all posts
Showing posts with label svn. Show all posts

06 October 2013

Integrando TortoiseSVN y JDeveloper

JDeveloper es una herramienta que ofrece integración con SVN, pero en mi caso prefiero utilizar TortoiseSVN en lugar de la funcionalidad integrada, lo cual suele ser algo incomodo al momento de trabajar con SVN ya que hay que ir por el explorador de ficheros.

Por suerte JDev tiene un apartado que ofrece integración con herramientas externas y es alli donde podemos integrar estas dos aplicaciones; al menos las operaciones mas usadas.

En la siguiente imagen se ve el resultado de integrar la funcionalidad de compare, update, log y revert.

Para registrar Tortoise como herramienta externa hay que ir a Tools->External Tools->New y elegir programa externo.

Luego como ejecutable hay que escribir el nombre del fichero exe de Tortoise y despues el comando que deseamos ejecutar (en la siguiente imagen se especifica que se ejecutara el comando diff)

En el siguiente paso especificamos en que lugares deseamos que aparezca este registro.

Finalmente continuamos hasta finalizar el asistente.

Los argumentos para las operaciones de "comparar con la última versión", actualizar, "ver historico de log" y deshacer son:
  • /command:diff /path:${file.path}
  • /command:update /closeonend:0 /path:${file.path}
  • /command:log /closeonend:0 /path:${file.path} 
  • /command:revert /closeonend:0 /path:${file.path}


Enlaces relacionados:
- FIN -

30 December 2010

Cliente SVN para Ubuntu 10

Existen diversos clientes SVN para Ubuntu, quizas el más usado es rapidsvn, de hecho fue el primero que conocí.

Pero yo estoy acostumbrado a utilizar tortoisesvn en windows ya que me da mayor potencia que los clientes svn integrados en eclipse, netbeans o jdeveloper.

Pues bien digamos que me canse de rapidsvn y decidí buscar una alternativa similar a tortoise, para grata sorpresa existe, su nombre es RabbitVCS, y al igual que tortoise se integra con el navegador de ubuntu (nautilus).

Seguí sus instrucciones de instalación (From the Tarball) y las del cliente client/plugin/nautilus/README y ahora tengo un cliente integrado con el navegador.

La interfaz y el uso es similar a tortoise, la única pega que le veo (por comodidad) que aunque le diga que guarde las credenciales de mi repositorio, no lo hace, pero bueno, es un mal menor.




- FIN -

17 May 2010

Buenas prácticas con subversion : Merging and Merge Tracking

En CollabNet se ha publicado un webcast, sobre mejores prácticas de la utilización de la característica merge que trae subversión; si! esa gran desconocida sobre todo en combinación con branch.

No esta demás decir que para acceder al webcast hay que registrarse.

He aquí un extracto de los objetivos.

The webinar will dig deeper looking at:
  • The different types of mergeinfo
  • When is mergeinfo not considered or recorded
  • Why you should be using 1.6.9 clients today
  • What’s coming with 1.7.0 for merge and mergeinfo


Enlace relacionado:

Subversion Best Practices: Merging and Merge Tracking

- FIN -

08 June 2009

Kenai Project vs Google Code

Hoy en día además de Sourceforge; Google, Sun, y Microsoft disponen de hosting gratuitos para proyectos "open source", y cualquier desarrollador puede acceder a ellos para almacenar sus proyectos; estos proyectos pueden ser evolucionados de forma colaborativa al mismo tiempo por distintas personas sin importar su localización.


Kenai Project
Es una iniciativa de Sun Microsystems, si se dispone de un SDN (Sun Developer Network) como es mi caso, el proceso de alta se simplifica. Pero para crear un proyecto hay que hacer una petición de creación y una vez que se reciba la respuesta se puede empezar a trabajar con él.

Entre sus principales carecterísticas ofrece:
  • Una buena variedad de sistemas de control de versiones, como pueden ser el utilizar Mercurial, SVN y Git
  • Perfil de usuarios
  • Forums
  • Wiki
  • Issue Tracking(Bugzilla/JIRA)
  • Listas de correo para poder comunicarse mejor entre los miembros del equipo y la comunidad
  • Integración con Netbeans (para el código fuente y el seguimiento de tareas)

http://www.kenai.com

Creación de un proyecto en Kenai con Netbeans 6.7 (5 min)

Creating a Kenai Project in NetBeans IDE 6.7

Bienvenida al proyecto Kenai (16 min)



Google Code
Para crear un proyecto en el hosting de Google Code hay que tener una cuenta en Google, una vez creado el proyecto podemos empezar a trabajar con él (subir código fuente)

Entre sus principales características ofrece:
  • Mercurial y SVN como sistemas de control de versiones
  • Perfil de usuarios
  • Wiki
  • Issue Tracking(usando el navegador)
http://code.google.com/hosting/
http://code.google.com/p/support/






Tanto en Google Code como en Kenai, hay que especificar el tipo de licencia que deseamos aplicar a nuestro proyecto al momento de su definición, cualquier IDE que disponga de conexión con SVN puede integrarse con estos, pero si desearamos utilizar Mercurial, o tener el seguimiento de incidencias integrado con el IDE, Kenai se lleva el gato al agua.

Recuerdo que antes, solo existía Sourceforge para el hosting de proyectos libres, ahora también estan Kenai y Google Code para proyectos principalmente Java o PHP y Codeplex para proyectos .Net.

- FIN -

16 October 2007

Hooks SVN en Linux

Este articulo viene a raíz de uno anterior llamado

Hooks para SVN - Comprobación de propiedades - Bloqueo de ficheros

Se basa en el mismo caso, pero esta vez en lugar de haberlo hecho en windows + .net se ha implementado en un Red Hat + bash y se accede bajo el protocolo http con un servidor Apache.

Lo que hay que tener en cuenta es que el usuario con el que se este ejecutando el servidor Apache tenga permisos de ejecución sobre el hook.

El código del pre-commit es el siguiente:


#!/bin/bash


function log(){


echo "$1" >> /opt/repos/proyecto/hooks/pre-commit-log.txt

}



log "-------------------------------------------------------------------"

log "Usuario : $(who) "

log "Fecha : $(date --d=now +"%Y-%m-%d %T %z") "


log "Repos : $1"

log "TXN : $2"

log ""


svnlooktool=$(echo "/opt/CollabNet_Subversion/bin/svnlook changed ${1} -t ${2}" )

log "Comando : $svnlooktool"


psoutsvnlook=$($svnlooktool)


log "RAW OUTPUT : "

log "$psoutsvnlook"

log ""


psoutsvnlook=$(echo "$psoutsvnlook" awk '{for (i=2; i<=NF && $1 !="D" ; i++) s=s " " $i; print s; s=""}') log "PROCESS RAW OUTPUT : " log "$psoutsvnlook" log "" log "PROCESS OUTPUT :" declare ok=0 echo "$psoutsvnlook" while read ii; do

len_ii=${#ii}
if [ "$len_ii" -gt 0 ]; then

svnlooktool_prop=$(echo "/opt/CollabNet_Subversion/bin/svnlook propget ${1} svn:needs-lock ${ii} -t ${2}" )

log "Comando : ${svnlooktool_prop}"


psoutsvnlook_prop=$(/opt/CollabNet_Subversion/bin/svnlook propget ${1} svn:needs-lock "${ii}" -t ${2})

log "svn:needs-lock($?) : ${psoutsvnlook_prop}"


len=${#psoutsvnlook_prop}

if [ "$len" -lt 1 ]; then


log "No se ha encontrado la propiedad svn:needs-lock "


#fichero de error

#echo "El fichero \"${ii}\" necesita tener la propiedad svn:needs-lock!" > ${filename_error}


let ok=$ok+1

exit $ok

else

log "svn:needs-lock encontrado!"


fi
fi

log ""

done



if [ $? -gt 0 ]


then

echo "Se debe informar la propiedad svn:needs-lock!" >&2

exit 1

fi


exit 0


Por cierto sr Guardiola, gracias por sus conocimientos de awk. Y ud. maestro Sebas claro, el rey de los asados :-)

- FIN -

18 September 2007

Hooks para SVN - Comprobación de propiedades - Bloqueo de ficheros

En determinadas ocasiones nos interesara poner atributos en nuestros ficheros de SVN, como por ejemplo para poder bloquearlos exclusivamente y asi evitarnos los fastidiosos merges e inconsistencias de codigo que en determinadas ocasiones se originan.

El atributo que se necesita para obligar el bloqueo exclusivo es el svn:needs-lock, y este ha de estar en todos nuestros ficheros del control de versiones; pero claro esta es una tarea engorrosa y algún miembro del equipo puede obiarlo por descuido :-p . Asi que no esta de mas comprobar la existencia del atributo en el servidor justo cuando hacen el commit de los ficheros.

Para ello SVN nos provee de una serie de hooks, en concreto el que se adapta a esta necesidad es el hook llamado pre-commit, que se ejecuta antes de confirmar la transacción, devolviendo un entero distinto de cero(-1) si no se cumple con las condiciones, con lo cual se realiza un rollback de la transacción.

Creo que no esta demas recalcar que en una transacción se pueden subir/actualizar/eliminar varios ficheros y que si la transacción falla ninguno de los ficheros afectados se actualiza en el servidor.

Pues bien para comprobar que todos los ficheros de la transacción tengan el atributo svn:needs-look habría que hacer lo siguiente:



  1. Crear nuestro hook llamado pre-commit(.pl, .py, .bat, .exe, ...), este recibe como parametros el repositorio y el numero de transacción actual.


  2. Recoger la lista de ficheros afectados con la utilidad svnlook utilizando la opción changed, pasandole el repositorio y la transacción en cuestión.


  3. Por cada fichero devuelto habria que volver a utilizar la utilidad svnlook, pero esta vez con la opción propget, pasandole el nombre de la propiedad a buscar, el repositorio, el fichero y finalmente el codigo de la transacción.


  4. Si alguno de las invocaciones svnlook proget da un error de propiedad no encontrada, se escribe por la corriente de salida de error el mensaje en cuestión y se devuelve un -1.



De esta manera, con este hook obligamos a que todos los usuarios que añadan nuevos ficheros pongan este atributo, y que aquellos ficheros que ya estan en el servidor sigan teniendolo, no sea que algún miembro del equipo lo quite por equivocación :-P

Un ejemplo de hook pre-commit en .NET lo podeis encontrar en la siguiente dirección :

Interactuando con programas externos a nuestra aplicación.

Un ejemplo de hook pre-commit en bash de Linux lo podeis encontrar en:

Hooks SVN en Linux



-FIN-

17 September 2007

Hooks python en SVN para Windows

Antes de empezar con este articulo sería recomendable ver primero Servidor de Subversion en Windows.

Subversion admite hooks, estos son equivalentes a los famosos triggers de base de datos.

Estos hooks se pueden programar en cualquier lenguaje ejecutable que admina el sistema operativo, es decir, podría ser un .bat .exe e incluso .js/.vbs (windows scripting host); pese a esto la gran mayoria de ejemplos estan hechos en perl y python, con lo cual opte por instalar python en mi servidor WS2003.

Lo primero habría que instalar pyton y las librerias para svn.


Los Hooks adminitidos para esta versión de subversion se encuentran en el directorio proyectos\hooks y son los siguientes:

start-commit.tmpl
pre-commit.tmpl
post-commit.tmpl
pre-revprop-change.tmpl
post-revprop-change.tmpl
pre-lock.tmpl
post-lock.tmpl
pre-unlock.tmpl
post-unlock.tmpl

Los ficheros tmpl son plantillas de hooks, para mas información sobre estos consultar la documentación expuesta en la web Implementing Repository Hooks



Bueno esto es basicamente lo que dice la documentación, pero ejecutando los ficheros .py me da el siguiente error:

no module named svn

Con lo cual siendo deciros que toda esta historia que os he contado, NO ME HA FUNCIONADO, a lo mejor por que no he profundizado mas en el tema, aunque ahora tengo otro lenguaje nuevo para trastear en mi windows... "python".

- FIN -

14 September 2007

Servidor de Subversion en Windows

Guia rápida de como iniciar un servidor SVN en Windows


Lo primero que habria que hacer es descargar subversion (svn-win32-1.4.5.zip) de la siguiente dirección :

http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100&expandFolder=8100&folderID=8100

Habria que descomprimir el zip, en mi caso lo he puesto en el siguiente directorio:
C:\borrame\svn145

Luego en una ventana del interprete de comandos ir al directorio antes mencionado.
Ahora habría que crear un repositorio :
C:\borrame\svn145\svnadmin create proyectos
(en este caso creo un repositorio llamado proyectos)

Una vez creado el repositorio tendríamos que configurar el control de acceso del fichero svnserve.conf, en este caso ubicado en C:\borrame\svn145\bin\proyectos\conf\svnserve.conf.
Para autorizar a los accesos anonimos leer y escribir habria que colocar lo siguiente:
anon-access = write

En caso de querer que todos los accesos sean con usuarios registrados habria que colocar lo siguiente:
[general]
anon-access = none
auth-access = write
password-db = passwd

Si se ha elegido controlar el acceso por usuarios, el fichero donde se ubican estos y sus contraseñas es passw ubicado en este caso en C:\borrame\svn145\bin\proyectos\conf\passw, y habría que registrar los usuarios después de la etiqueta [users]

[users]
emmerson = emmerson01
usuario1 = password1
usuario2 = password2
usuarioN = passwordN

Pues bien despues de todo esto estamos listos para iniciar el servidor de SVN:
svnserve -d --listen-port 3109 --listen-host 169.169.169.169 -r c:/svn145/bin

Pues bien ya hemos iniciado el servidor, ahora la ruta para conectarnos a este desde cualquier cliente SVN ( por ejemplo subclipse ) es :
URL de SVN : svn://169.169.169.169:3109/proyectos

-FIN-