SourceForge es una central de desarrollos de software que controla y gestiona varios proyectos de software libre y actúa como un repositorio de código fuente.

SourceForge.net es hospedado por VA Software y corre en
una versión del software SourceForge.

Source Forge gestiona a través de proyectos repositorios SVN, Hg (mercurial) y Git.

Cada usuario puede crear sus proyectos y repositorios de forma gratuita.

Estos proyectos suelen ser open source (código libre y abierto), en los cuales podemos participar, descargar el código, mejorar el código, enviar informes de errores, solicitar cambios, étc.

Creación de nuevo proyecto

Protocolos utilizados

SSH

HTTPS

SSH

• Es necesario crear las llaves públicas y privadas en nuestra PC
• La llave pública debe ser copiada al repositorio
• Gracias a estas llaves no será necesario ingresar usuario y contraseña al momento de hacer un push al repositorio

HTTPS

• Más sencillo de utilizar por el hecho de que no involucra llaves públicas y privadas.
• Cada vez que se desse realizar un push al repositorio es necesario ingresar usuario y contraseña de SourceForge, en este caso.

• Gratuita y de código libre. Sistema de control de versiones multiplataforma.
• Herramienta para el control de código fuente distribuído. Se enfoca en controlar el versionado del código y archivos.
• Permite que múltiples usuarios puedan trabajar de una forma automatizada  y cómoda en el mismo proyecto, haciendo uso de distintas ramas de desarrollo, permitiendo versionar el código y generar etiquetas de acuerdo al estado del proyecto y el código fuente.
• Mantiene un historial de todo el proyecto, desde sus inicios hasta el estado actual.
• Maneja eficientemente proyectos de cualquier tamaño, y ofrece una sencilla e intuitiva interfaz.
• No sólo se utiliza con código fuente, sino que soporta cualquier tipo de archivo, como documentos, imágenes, binarios, étc.

• Escrita en su mayoría en Python. En C se han escrito algunas partes que requieren gran velocidad, como diff.
• Las principales metas de desarrollo de Mercurial incluyen un gran rendimiento y escalabilidad; desarrollo completamente distribuido, sin necesidad de un servidor; gestión robusta de archivos tanto de texto como binarios; y capacidades avanzadas de ramificación e integración, todo ello manteniendo sencillez conceptual.
• Incluye una interfaz web integrada.
• Creador y desarrollador principal: Matt Mackall.
• El código fuente se encuentra disponible bajo los términos de la licencia GNU GPL versión 2.

• Mercurial es una herramienta pensada para usarse en línea de comandos.
• A pesar de poseer múltiples interfaces gráficas que trabajan sobre las aplicaciones de la línea comandos, se es mucho más productivo si se aprende a utilizar correctamente la consola o terminal.

Documentación

• Oficial: www.mercurial-scm.org/guide
• hginit: hginit.com
• En español: www.mercurial-scm.org/wiki/SpanishTutorial

Sistema de Control de Versiones

Tiene una estructura similar a un sistema de archivos. La diferencia está en que se puede acceder a distintas versiones de los archivos y operar con estas versiones. Es decir: Es un sistema de ficheros con versionado.

Flujo de trabajo (workflow)

• Debido a la flexibilidad para colaborar en proyectos que proveen este tipo de herramientas, existen múltiples flujos de trabajo.
• Cada equipo implementará el que le resulte más conveniente.
• Cada desarrollador es tanto un nodo como un repositorio: cada desarrollador puede tanto contribuir a otros repositorios, como servir de repositorio público sobre el que otros desarrolladores pueden basar su trabajo y contribuir a él

Ramas (branches)

• Permite realizar un trabajo paralelo sin afectar a la rama principal.
• En mercurial, las ramas principales suelen llamarse default, y suelen ser las más importantes, las que derivan el código que va a producción.

• Existe también la posibilidad de crear ramas de ramas o de mezclarlas entre ellas, complicando así el grafo generado.

• Hay que tener en cuenta que, durante la mezcla de código, es posible que el algoritmo de mezclado falle, así que es buena idea combinar estas técnicas con robustas baterías de pruebas.

Hooks

Los repositorios pueden lanzar acciones automáticas cuando se producen ciertos eventos. Por ejemplo, podrían enviarnos un e-mail cuando una rama se mezcla con la rama principal, o comprobar que el código cumple ciertos criterios de calidad.

Múltiples repositorios (mirrors)

• Existe la opción de tener repositorios remotos réplica. Esto significa que podemos sincronizar nuestros cambios contra una de estas réplicas y ésta se sincronizará tarde o temprano con otra de las réplicas.

• La sincronización entre repositorios puede ser manual o automática, y puede dar lugar a un flujo de trabajo distinto según se necesite. 

Commit

• Se refiere a la idea de consignar un conjunto de cambios "tentativos" de forma permanente.
• Es obligatorio que tengan un mensaje para que sea más fácil para los demás desarrolladores conocer los cambios, ya que explicitar esto de forma textual es más entendible para el ser humano.

Línea de comandos

$ hg [comando] [parámetros]

$ hg help

Ejecutar hg

Ayuda

Comandos

Uso en conjunto con SourceForge

Comando para clonar el repositorio

Se crea una nueva carpeta. Se clonó un repositorio vacío.

Archivo de configuración

Creación de un nuevo archivo

Agregar el archivo al repositorio

$ hg add .

Generar commit de archivos agregados

$ hg commit -m "Mensaje..."

Ver ramas del repositorio

$ hg branches

Subir archivos al repositorio central

$ hg push

Bajar cambios del repositorio central

$ hg pull

Visualizar repositorio en SourceForge

Ramas

Último commit que modificó el archivo

Archivos mostrados en forma de directorio

Etiquetas

Ver logs de commits en línea de comandos

$ hg log

Otro programador clona el repositorio y modifica el archivo

$ hg clone [url-de-repositorio] [nombre-de-la-carpeta]

Realiza cambios

Visualiza cambios con diff

Agrega cambios y los envía al repositorio central para que el otro programador pueda verlos

Primer programador recibe cambios, modifica y agrega un archivo

$ hg merge # Mezclar cambios

Nuevo archivo y nueva funcionalidad

Sube cambios

Segundo programador

Repositorio en SourceForge resultante

Es una interfaz gráfica y una serie de aplicaciones para el sistema distribuído de control de versiones Mercurial.

Incluye extensiones para Gnome/Nautilus para GNU/Linux y herramientas de línea de comandos.

Text

Text

http://tortoisehg.bitbucket.org/

Clonar un repositorio

Clonar un repositorio

Repositorio clonado

Commit

Nuevo archivo

Agregar un archivo

Nuevo Commit

Barra de íconos de fácil acceso 

Repositorio remoto

• Servidor de integración continua, gratuito, open-source y actualmente uno de los más empleados para esta función.

• Desarrollado bajo el lenguaje Java.

• Corre en un servidor que es un contenedor de servlets, como Apache Tomcat.

• Soporta herramientas de control de versiones como CVS,Subversion, Git, Mercurial, Perforce y Clearcase y puede ejecutar proyectos basados en Apache Ant y Apache Maven, así como scripts de shell y programas batch de Windows.

¿Qué es?

Basado en el proyecto Hudson, creado por Kohsuke Kawaguchi (Sun).

Años más tarde Oracle compra Sun, y la comunidad de Hudson decide renombrar el proyecto a Jenkins y migrar el código a Github .

No obstante, Oracle sigue manteniendo y trabajando en Hudson.

Instalación

Antes de empezar debemos asegurarnos de que tenemos las dependencias de Java instaladas. En caso de que no sea así las instalaremos mediante:

sudo apt-get install openjdk-7-jre and openjdk-7-jdk

Instalando...

Usamos como fuente los repositorios de Jenkins para asegurarnos de que estamos instalando la última versión disponible.

*Por defecto Jenkins escucha en el puerto 8080.

# Agregar llave de repositorio
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key \
            | sudo apt-key add -

# Agregar repositorios de jenkins a las fuentes
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > \
            /etc/apt/sources.list.d/jenkins.list'

# Actualización de base de datos de repositorios e instalación
sudo apt-get update
sudo apt-get install jenkins

Dar seguridad a Jenkins

Jenkins viene sin seguridad (accesible por cualquier persona que acceda a la url )

• Acceder a la configuración global de seguridad delservidor de Jenkins (http://servidor/jenkins/configureSecurity/)

• Marcar la casilla 'Activar seguridad'.

• En Seguridad marcar 'Usar base de datos de Jenkins ' y  'Permitir que los usuarios se registren'.

• Seleccionar la 'Configuración de seguridad' como autorización y dentro de ella le damos permiso de lectura al usuario Anónimo.

• En  textbox de abajo ingresar  nombre de usuario que vaya a ser administrador y dar click en el botón de añadir. Aparecerá en la matriz una nueva fila para este usuario para la cual se deberá marcar todas las casillas

• Guardar.

Ejecutar:

• Dar de alta la cuenta del usuario con permisos de admin:

acceder a la URL de nuestro servidor de Jenkins y clickear  "Registrarse" o "Crear cuenta". (Verificar  que el nombre de usuario coincide con el que ingresado para poder asignar los permisos).

• Volver a la configuración global de seguridad de nuestro servidor y desmarcar la opción de "Permitir que los usuarios se registren"  (evitar que se registre gente no deseada).
• Los  usuarios que querramos que accedan al sistema podrán ser dados de alta manualmente desde la gestión de usuarios de Jenkins (http://servidor/securityRealm/).

sudo service jenkins start

Plugins

Existen multitud de plugins que permiten cambiar el comportamiento de Jenkins o añadir nueva funcionalidad.

Los más usados (mayo 2016)

Javadoc

Añade soporte Javadoc a Jenkins. Esta funcionalidad solía ser una parte del núcleo, pero a partir de Jenkins 1.431, se separó en diferentes plugins.

Mailer

Permite configurar las notificaciones de correo electrónico con los resultados de los builds. Para ello se debe configurar el servidor de correo. Jenkins enviará un correo electrónico a los destinatarios cuando se produce un cierto acontecimiento importante:

1. Todo build fallido

2. Un build exitoso después de uno fallido

3. Un build inestable después de uno exitoso

4. A menos que se configure, cada build inestable provoca un nuevo mail

External-monitor-job

Añade la posibilidad de controlar el resultado de los trabajos

realizados externamente.

Credentials

Permite almacenar credenciales en Jenkins. Proporciona una

API estándar para otros plugins para almacenar y recuperar

diferentes tipos de credenciales.

Características visibles de usuario:

- Pantalla de "Administrar credenciales" en la pantalla "Administrar

Jenkins". Permite administrar el sistema y las credenciales globales.

- Si está utilizando la seguridad Jenkins, cuando se va a "Usuarios" / su nombre de usuario / "Configuración", verá la opción para administrar las credenciales personales.

- En cualquier lugar donde se necesitan esas credenciales, hay una lista desplegable de las credenciales apropiadas disponibles para seleccionar.

- Cuando llegue el momento de cambiar la contraseña, sólo la cambia una vez.

Ssh-slaves

Permite administrar los esclavos que se ejecutan en

máquinas * nix a través de SSH. Añade un nuevo

tipo de método de lanzamiento de esclavos. Este

método de lanzamiento:

- Abre una conexión SSH al host especificado como el

nombre de usuario especificado.

- Comprueba la versión por defecto de Java para ese usuario.

- [No se ha implementado todavía] Si la versión por defecto

no es compatible con slave.jar de Jenkins, trata de encontrar

una versión de Java que lo sea.

- Una vez que se cuenta con una versión adecuada de Java, copia la última slave.jar a través de SFTP.

- Inicia el proceso de esclavo.

Dificultades y dudas

¿Cómo se maneja la interfaz gráfica?

(Aguante la consola)

¿Cómo puedo saber en qué branch estoy trabajando?

"hg branches" sin argumentos muestra las branches locales y resalta la que estás revisando.

¿Cuándo debo hacer commits?

Una buena práctica  es hacer commits por cambios lógicamente separados.

Los commits son "entradas de un libro de registro", siempre que se haya realizado un cambio que vale la pena señalar, grabalo en un commit.

Una opción popularmente aceptada es permitir a cualquiera commitear localmente las veces que desee, pero antes de hacer push a los commits locales, deben ajustarlos.

¿Por qué no puedo ver los cambios en el repositorio remoto después de "hg push"?

En general, si se hace push para actualizar el branch que no tiene hecho un checked out en un repositorio remoto, los archivos del árbol de trabajo no se actualizarán.

Esto es  por precaución, para evitar conflictos entre los cambios que  hace el push y los otros en el arbol de trabajo.

Si se esta seguro de lo que se hace, pueden hacer “hg reset –hard” en el lugar deseado para hacer push. Se perderan TODOS los cambios hechos en ese lugar, reseteando el arbol de trabajo a la version mas nueva que se hizo push.

¿Cómo puedo saber quién hizo un cambio específico a un archivo en mi repositorio?

El comando "hg blame" permite rastrear rápidamente quien hizo un cambio específico a un archivo. Desde el repositorio local uno puede ejecutar ese comando con el parámetro –L especificando qué líneas te interesan.

¿Cómo puedo ver el historial de cambios de mi branch o repositorio?

Para un historial local, uno puede utilizar el comando "hg log" para ver una lista del historial de commits para un branch local en la línea de comandos. También se puede utilizar la herramienta gráfica gitk para ver el historial de una branch local.

Por qué a veces me indica que “no estoy sobre ninguna branch”?

Significa que el usuario se encuentra ubicado en en una HEAD separada y puede ser que pierda commits

¿Cómo hago que me ignore archivos?

• .hg/info/exclude o .hg ignore.
• .hg/info/exclude es local a su repositorio solamente, y no compartida por otros que podrían entrar desde su repositorio.
• .hg ignore es la más utilizada, ya que puede ser revisada en el repositorio y de ese modo compartido automáticamente con todos los usuarios del proyecto.

¿Cuál es la diferencia entre fetch y pull?

Unas definiciones breves:

Fetch: Descargar (nuevos) objectos y la head de otro repositorio.

Pull: Hace Fetch, y luego merge lo que se ha descargado con el desarrollo actual

¿Cuáles son las diferencias de of HEAD, master y origin?

• HEAD: Significa “cuál es mi punto en el repositorio actual”

  En el caso de que el Head se refiera a commit no es a la punta de cualquier branch. Esto se llama una "cabeza separada" (detached head).

• Master: El nombre por defecto que mercurial crea cuando estas creando por primera vez un respoitorio. En muchos casos, “master” significa “la branch principal”.
• Origin: El nombre por defecto que mercurial le asigna a tu respositorio remote principal. Su espacio de trabajo tiene su propio repo. Lo más frecuente es hacer push a algún repo remoto que usted y todos sus compañeros de trabajo hacen push. Ese repo remoto es casi siempre llamado origin.