Guía de laboratorio

Apuntes del Experto

Los apuntes, trasparencias y demás material docente se encuentran en un sitio web restringido a los alumnos del Experto. Puedes acceder a esta zona pinchando en el recuadro correspondiente (azul) en la web pública del Experto (http://web.ua.es/especialistajava) o escribiendo directamente la URL http://www.jtech.ua.es/j2ee/restringido/. Una vez introduzcas tu usuario de Experto Java Enterprise y tu contraseña podrás acceder a esta web.

El login en este sitio web es las iniciales de tu nombre y tu primer apellido. Por ejemplo, si el nombre del alumno es Pedro Pérez, su login es pperez

Si deseas cambiar tu contraseña (o no la recuerdas), puedes pulsar en el enlace correspondiente. Se enviará un mensaje a tu dirección de correo con un enlace con el que podrás modificar la contraseña.

Moodle

Vamos a utilizar Moodle como plataforma de trabajo colaborativo. La usaremos para gestionar los foros, las calificaciones de los ejercicios y alguna que otra encuesta que iremos presentando. Se accede pinchando en el recuadro correspondiente (amarillo) en la web del Experto o escribiendo directamente la URL http://moodle.jtech.ua.es.

Al igual que el resto de recursos de acceso restringido, el usuario de acceso será las iniciales del nombre y tu primer apellido. La contraseña inicial será el DNI, y la primera vez que te registres te pedirá una nueva contraseña.

Uno de los elementos principales que utilizaremos de Moodle son los foros, que utilizaremos para resolver dudas y para las sesiones de consulta on-line del proyecto de integración. Desde el frontal de Moodle se puede acceder directamente a estos foros. Se llaman Foro general y Foro sesiones on-line. Para poder utilizar correctamente el foro es muy importante que actualices tu foto. Para eso, debes pinchar en tu nombre (en la zona de Usuarios en línea o abajo a la derecha, donde pone Usted se ha autentificado como) y seleccionar la pestaña Editar información. Allí puedes colocar tu foto. Cuando todos tenemos la foto es mucho más sencillo contestar e interactuar en el foro. La siguiente imagen muestra un ejemplo del foro general en la edición 2009-2010 del especialista:

En la página principal del curso puedes encontrar también enlaces a las tareas de entregas de ejercicios de cada uno de los módulos, una vista del calendario Google con las clases del Experto y una vista del Twitter del Experto:

Los laboratorios en los que se realizarán las prácticas están gestionados por la Escuela Politécnica Superior. Para acceder a ellos se debe contar con una cuenta de usuario en la EPS. Es posible cambiar la contraseña entrando como usuario anónimo en la zona de servicios de la EPS (más información).

Al arrancar el ordenador deberás seleccionar como sistema operativo Linux Ubuntu. En este sistema operativo se encuentra el programa VirtualBox con el que se pondrá en marcha la MV en la que se realizarán las prácticas.

Trabajaremos directamente con la imagen de la MV en el disco externo SSD. En los ordenadores de la EPS no podremos aprovechar la velocidad del disco, porque los puertos USB de los ordenadores son 2.0. A pesar de ello, el rendimiento será aceptable. Si dispones de un ordenador con un puerto USB 3.0, podrás aprovechar completamente la velocidad del disco SSD.

Uno de los elementos más importantes de las prácticas del curso es la MV con una distribución de Linux Ubuntu y con las herramientas necesarias para realizar los ejercicios. Su uso te hace sencillo continuar en casa los ejercicios y prácticas realizados en clase y garantiza que todos utilizamos el mismo entorno de trabajo. También nos hace inmunes a posibles cambios en las instalaciones de los ordenadores de la EPS.

El disco imagen de la MV original se encuentra en el disco externo, y también comprimida en la zona restringida de apuntes de la web del Experto y dividida en 7 ficheros 7z de unos 700 MB cada uno:

• ExpertoJava2012.7z.001
• ExpertoJava2012.7z.002
• ExpertoJava2012.7z.003
• ExpertoJava2012.7z.004
• ExpertoJava2012.7z.005
• ExpertoJava2012.7z.006
• ExpertoJava2012.7z.007

La MV Ubuntu es compatible con las últimas versiones VirtualBox. La versión de las Guest Additions instalada en la MV es la 4.1.20, que corresponde a la versión de VirtualBox instalada en los ordenadores de la EPS.

VirtualBox es multiplataforma y opensource. Existen versiones para Windows, Mac y Linux y es posible trabajar con la misma máquina virtual en distintos sistemas operativos. Puedes, por ejemplo, trabajar en la EPS en Windows y después continuar el trabajo en casa en Mac. En el disco duro externo hemos incluido las versiones de Mac y Windows.

Máquina Virtual Ubuntu

La instalación de Ubuntu en la MV es la 11.04, con las actualizaciones disponibles a Septiembre de 2012.

En la MV se ha creado el usuario expertojava con la contraseña expertojava. Tendrás que utilizar este login para entrar en el sistema, para ejecutar comandos en modo superusuario o cuando se bloquee la pantalla:

El disco de la máquina virtual tiene una capacidad máxima de 25 GB. Con las aplicaciones instaladas ocupa alrededor de 9 GB.

En la máquina virtual se ha instalado el software que vamos a utilizar a lo largo de todos los módulos del curso:

• Plataforma Java: 1.6.0_33
• Entornos de desarrollo
  • Eclipse Indigo
  • NetBeans 7.2
  • Spring Tool Suite 3.0.0
  • Grails Tool Suite 3.0.0
• Servidores de aplicaciones
  • Tomcat 7.0.29
  • GlassFish 3.1.2
  • GlassFish ESB v2.2
  • WebLogic 12.1
• Base de datos: MySQL 5.1 (contraseña del usuario root: expertojava)
• Herramientas adicionales: Maven, TortoiseHG, Meld

Paso a paso: cómo crear la MV Ubuntu en el ordenador anfitrión

Lo primero que tenemos que hacer en el ordenador de la EPS es crear con VirtualBox la máquina virtual en la que vamos a trabajar. Vamos a crear la MV para que trabaje con la imagen vdi en el disco externo (Experto Java 2012.vdi).

1. Arranca VirtualBox en el ordenador anfitrión y crea una nueva MV de tipo Linux Ubuntu con el nombre Experto Java EE

2. Define el tamaño de la memoria de la MV en un valor suficiente para trabajar cómodamente con el entorno de trabajo y que no comprometa el rendimiento del ordenador anfitrión. El tamaño recomendable es alrededor de 1 GB. Los ordenadores de la EPS tienen 2 GB de memoria y 1 GB está en límite de lo recomendable. Pondremos algo menos, 980 MB.

3. Ahora debemos vincular la imagen vdi del disco externo con la máquina virtual que estamos creando. Para ello, en la pantalla Disco Duro Virtual seleccionamos la opción Usar un disco duro existente y seleccionamos el fichero Experto Java 2012.vdi en el disco duro externo:

Debes realizar un proceso similar en tu ordenador de casa, para crear allí una MV conectada también a la misma imagen vdi del disco externo.

La configuración de la máquina virtual creada se guarda en la carpeta VirtualBox VMs del directorio de usuario.

4. Terminamos configurando el número de procesadores de la MV. Es muy recomendable trabajar con al menos 2 procesadores, porque el rendimiento aumenta espectacularmente. Para ello debemos seleccionar la opción Configuración > Sistema > Habilitar IO APIC:

Y después definir más de 1 procesador en la pestaña de Procesador.

Instalación de Guest Additions

Es recomendable instalar las Guest Additions. Con ellas instaladas es posible pasar del SO invitado (Ubuntu) al SO anfitrión sin tener que pulsar ninguna combinación de teclas, sólo moviendo el cursor. También son útiles para copiar y pegar texto entre ambos sistemas operativos, así como para cambiar fácilmente la resolución de la pantalla.

Las Guest Additions ya están instaladas en la imagen inicial. Si en algún momento actualizas VirtualBox, deberás también actualizar la versión de Guest Additions. Para ellos debes seleccionar la opción Dispositivos > Instalar "Guest Additions" del menú de Virtual Box que aparece cuando estamos ejecutando la MV. Esto montará un disco en Ubuntu que tiene activada la opción de autoejecución. Acepta la autoejecución y se lanzará el comando que instala el Guest Additions en el host invitado. Una vez instaladas, debes desmontar el CD y reiniciar Ubuntu.

Compartición de directorios con el anfitrión

Una vez instaladas las Guest Additions es posible compartir directorios entre el ordenador invitado (Ubuntu) y el anfitrión (Windows, Mac, etc.). Para ello selecciona la opción Dispositivos > Directorios Compartidos y pulsa en el icono para añadir un nuevo directorio transitorio (no se guardan los datos de un arranque a otro).

Aparecerá una ventana en la que debes indicar la ruta del directorio del ordenador anfitrión que se quiere compartir y un nombre simbólico con el que identificar ese directorio. Para indicar la ruta del directorio en el anfitrión puedes también escoger la opción del desplegable que abre el navegador de archivos para seleccionarlo gráficamente.

Crea el directorio Compartido con MV en el ordenador anfitrión, escógelo y escribe como nombre simbólico Compartido

De esta forma estamos creando un dispositivo que puede ser montado en el sistema y que tiene como nombre Compartido y que estará conectado con el directorio Compartido con MV en el ordenador anfitrión

Por último debemos crear un directorio en la MV que haga de punto de montaje del dispositivo que acabamos de crear. Lo podemos llamar con cualquier nombre, por ejemplo Host. Y después usamos el comando mount como root para montarlo:

$ cd Escritorio 
$ mkdir Host
$ sudo mount -t vboxsf -o uid=1000,gid=1000 Compartido Host

Los parámetros uid=1000,gid=1000 hacen que el propietario de la carpeta compartida sea el propio usuario, con lo que no es necesario ser root para explorarla.

Para desmontar el directorio llamamos al comando umount:

$ sudo umount Host

En el curso vamos a utilizar distintos entornos de programación. Los más importantes van a ser Eclipse y NetBeans, que son también los más utilizados por la comunidad de desarrolladores Java. Cada entorno tiene características propias y está mejor adaptado para ciertas tecnologías y configuraciones. Por ejemplo, NetBeans está perfectamente integrado con el servidor de aplicaciones GlassFish, ya que ambos son productos de Oracle, y será la combinación que utilizaremos en los módulos de aplicaciones enterprise. Eclipse es un entorno de desarrollo open source muy configurable y extensible. Es también la base de varios entornos de desarrollo utilizados para tecnologías específicas, como Spring o Grails. Vamos a utilizarlo en los primeros módulos del curso.

El trabajo en Eclipse se organiza en proyectos que se guardan en lo que Eclipse denomina espacios de trabajo (Workspaces). Un espacio de trabajo se corresponde con un directorio físico del disco duro y los proyectos se suelen corresponden con subdirectorios suyos. Para organizar mejor los trabajos que se irán realizando, crearemos un espacio de trabajo por cada módulo del Experto en el que guardaremos los proyectos correspondientes a ese módulo.

Un espacio de trabajo puede contener distintos proyectos. Cada proyecto puede contener (entre otras cosas) un conjunto de clases Java y un conjunto de librerías. Los proyectos pueden estar relacionados, de forma que uno utilice clases o librerías Java que residen en otro. Veremos todo esto con detalle en el módulo Java y Herramientas de Desarrollo. En la sesión de hoy estudiaremos los aspectos más sencillos relacionados con los proyectos. Entre otras cosas, cómo crearlos, modificarlos, trabajar con el sistema de control de versiones Mercurial y subirlos a BitBucket para realizar la entrega de los ejercicios desarrollados.

El nombre del directorio del espacio de trabajo no es importante, porque no es más que una carpeta contenedora. Para poder identificarlos correctamente, vamos a guardarlos todos dentro del directorio /home/expertojava/workspaces y vamos a identificarlos con las iniciales del módulo, seguido de -expertojava:

• workspaces/lja-expertojava: Lenguaje Java Avanzado
• workspaces/jpa-expertojava: Frameworks de Persistencia - JPA
• workspaces/cw-expertojava: Componentes Web y Servicios REST
• workspaces/spring-expertojava: Frameworks de Desarrollo de Aplicaciones - Spring
• workspaces/grails-expertojava: Frameworks Ágiles - Grails
• workspaces/jsf-expertojava: Componentes de Presentación - JSF
• workspaces/servd-aplic-expertojava: Servidores y Arquitecturas de Aplicaciones
• workspaces/comp-ee-expertojava: Componentes Enterprise
• workspaces/servc-web-expertojava: Servicios Web y SOA
• workspaces/proyint-expertojava: Proyecto Java EE

Creación de espacios de trabajo y proyectos en Eclipse

1. Vamos a empezar creando un espacio de trabajo de prueba para practicar las características más importantes de los espacios de trabajo y de Mercurial. Cuando arrancamos Eclipse por primera vez aparece un cuadro de diálogo en el que nos pide el espacio de trabajo en el que vamos a trabajar. Por defecto, Eclipse sugiere el directorio llamado workspace en el home del usuario. Podemos abrir otro espacio de trabajo pulsando el botón Browse o escribiendo su ruta en el campo de texto. Eclipse abrirá el directorio correspondiente, o creará un nuevo directorio si no existe.

Creamos el espacio de trabajo /home/expertojava/workspaces/prueba. Para ello escribe la ruta /home/expertojava/workspaces/prueba y abre el espacio de trabajo

2. Abre un terminal y comprueba que se ha creado el directorio prueba y el fichero .metadata dentro de él:

$ cd /home/expertojava/workspaces/prueba
$ ls -la
total 12
drwxr-xr-x 3 expertojava expertojava 4096 2012-09-23 11:14 .
drwxr-xr-x 3 expertojava expertojava 4096 2012-09-23 11:14 ..
drwxr-xr-x 4 expertojava expertojava 4096 2012-09-23 12:29 .metadata

2. Vamos a empezar creando un pequeño proyecto Java. Arrancamos Eclipse con el espacio de trabajo workspace/prueba definido. Tendrá el siguiente aspecto:

Eclipse organiza los paneles en perspectivas. En la esquina superior derecha se puede cambiar la perspectiva con la que se está trabajando. Vamos a trabajar con la perspectiva Java para proyectos Java de escritorio (en los primeros módulos Lenguaje Java Avanzado y Frameworks de Persistencia) y con la perspectiva Java EE en el resto de módulos en los que se despliegan las aplicaciones Java en servidores de aplicaciones.

Una perspectiva consiste en un conjunto de paneles (denominados en Eclipse vistas) organizados en una determinada disposición. Cada panel está orientado a una determinada actividad. Eclipse contiene una enorme cantidad de vistas que permiten gestionar múltiples aspectos del desarrollo: listas de tareas por hacer, baterías de pruebas, despliegue, edición y compilación, etc. Todas estas vistas se organizan en un conjunto de perspectivas predefinidas.

Puedes reconfigurar el aspecto de la perspectiva moviendo paneles de sitio, cambiando sus dimensiones, quitándolos o añadiendo paneles nuevos. En cualquier momento puedes escoger la opción Window > Reset Perspective... para volver a la disposición original de la perspectiva.

Las perspectivas que vamos a utilizar principalmente en el curso son Java y Java EE.

Escoge la perspectiva Java y elimina la vista Task List porque no la vamos a utilizar.

3. El panel vertical izquierdo es el destinado a contener los proyectos, ahora está vacío. Para crear un proyecto podemos escoger la opción File > New > Java Project... o pulsar el botón derecho sobre el panel de proyectos y escoger la opción New > Java Project.... En cualquiera de estos casos, aparecerá un asistente que nos guiará para crear el tipo de proyecto que deseemos. En este caso vamos a crear nuestro primer proyecto Java. Escribimos como nombre del proyecto agenda:

Cuando pulsamos Finish Eclipse crea el proyecto, creando un directorio nuevo en el espacio de trabajo. Aparece como una carpeta en el panel de proyectos.

4. Una vez creado el proyecto, vamos a crear en él un pequeño programa Java, que nos va a servir para demostrar algunas de las características de Eclipse. En el programa vamos a definir una clase Tarjeta con los datos de una tarjeta de contactos: id (int), nombre (String) y eMail (String) y una clase Main con el programa principal de la aplicación, que crea un par de tarjetas, las guarda en un array y lo recorre para mostrarlas por la salida estándar.

Todas las clases deben estar en el paquete es.ua.jtech.pres. Es habitual utilizar como prefijo en el nombre del paquete la URL de la empresa u organización que desarrolla el código en orden inverso. De esta forma se garantiza que el nombre completo de la clase es único y no coincide con otras clases desarrolladas por otras organizaciones. Además terminaremos con el nombre corto del módulo, para que no haya problema si definimos las mismas clases en distintos módulos. Como estamos en este momento en la Presentación del Experto, utilizaremos el nombre corto pres.

Para crear una clase seleccionamos New > Class y rellenamos el cuadro de diálogo con el nombre de la clase y el paquete. Comenzamos con la clase Tarjeta:

Escribimos la clase Tarjeta con los campos indicados, los getters y setters correspondiente y un constructor que cree una tarjeta nueva a partir de un identificador y un eMail. Podemos probar a utilizar la ayuda de Eclipse para generar código con la opción Source > Generate Getters and Setters ... o Source > Generate Constructor using fields .... Generamos también de forma automática el método toString.

5. Crea una clase Main en la que debes declarar un array de tarjetas, crear y añadir un par de tarjetas y recorer el array imprimiendo sus datos en la salida estándar. Escribe el código probando el atajo del teclado Ctrl+Espacio de Eclipse para completar un nombre de variable, un método o incluso una expresión for. Si no recuerdas cómo se crea un array en Java puedes consultarlo en el tutorial de Java de Oracle.

La estructura de clases que aparece en el proyecto es esta:

6. Ejecuta la aplicación con la opción Run > Run As > Java Application. Una forma rápida de acceder a esta opción es con el icono de play en la barra superior de eclipse.

7. Para terminar, añadimos la vista Navigator que nos permite explorar la estructura de archivos creados en el disco duro. La podemos colocar junto a la vista Package Explorer:

Vemos que Eclipse realiza automáticamente todo el trabajo de compilar las clases .java a ficheros .class y colocarlos en los directorios correspondientes a sus paquetes. También podemos ver los ficheros .settings, .classpath y .project donde guarda distintas características del proyecto. Es recomendable dejar esta vista Navigator porque la utilizaremos más de una vez para visualizar la estrucutura real del sistema de archivos.

El sistema de control de versiones Mercurial

Durante el curso vamos a trabajar con el sistema de control de versiones Mercurial. Mercurial es un sistema de control de versiones distribuido, que permite gestionar las versiones del desarrollo de software de forma local, en tu propio disco duro, y que además permite publicar los proyectos a repositorios remotos que pueden ser compartidos por múltiples usuarios.

A continuación vamos a ver una breve introducción a Mercurial, con las indicaciones básicas y necesarias para trabajar en el Experto. Si quieres profundizar más en el sistema te recomendamos la siguiente bibliografía:

• Tutorial de Mercurial de Joel Spolsky
• Mercurial: the Definitive Guide (Biblioteca de la UA)

Características de Mercurial (y otros sistemas distribuidos como Git) lo diferencian radicalmente de otros SCV como CVS o SVN:

• Mercurial guarda en cada revisión la información de los cambios que se han introducido en los ficheros con respecto a la versión anterior. Es un sistema de control de versiones incremental, en el que para obtener el estado de un fichero se deben aplicar sucesivamente todos los cambios que se han ido registrando en los commits en los que ha participado.
• Mercurial maneja perfectamente las ramas. Es muy sencillo crear ramas paralelas para trabajar en características separadas de un desarrollo y posteriormente mezclarlas en una única rama final. Los comandos de mezclado (merge) de ramas son muy robustos.
• Mercurial tiene un carácter distribuido. Es posible publicar (push) los cambios de un repositorio local en un repositorio remoto. Mercurial comprueba si hay alguna revisión común en ambos y crea una rama nueva en el repositorio común a partir de ella. Otros desarrolles conectados al repositorio remoto podrán bajarse (pull) los nuevos cambios a su repositorio local y mezclarlos con la versión desarrollada.

Es importante tener en cuenta que Mercurial se utiliza tanto para trabajar controlando las versiones del repositorio local, como actualizando un repositorio remoto:

• En modo local, Mercurial permite guardar múltiples versiones de los proyectos que estás desarrollando, compararlas, volver atrás y recuperar alguna versión anterior, mantener más de una rama de desarrollo abierta, etc.
• En modo remoto, Mercurial permite conectar el repositorio local a un repositorio global y publicar allí los últimos cambios o descargar de él las últimas modificaciones que han subido otros compañeros que están conectados al mismo repositorio.

En la siguiente figura se muestra el comportamiento básico de un sistema de control de versiones distribuido como Mercurial. Cada desarrollador trabaja sobre su repositorio local y cuando lo considera oportuno publica los cambios en un repositorio remoto al que tienen acceso todos los miembros del equipo. En cualquier momento los desarrolladores consultan el repositorio remoto y actualizan sus repositorios locales con los cambios de los compañeros.

Comandos de Mercurial sobre repositorios locales

Lista de los comandos más utilizados de Mercurial para trabajar con repositorios locales:

Comandos de Mercurial sobre repositorios remotos

Lista de los comandos más importantes de Mercurial para trabajar con repositorios remotos:

Ciclo de trabajo habitual cuando se está trabajando en equipo

El ciclo de trabajo habitual con Mercurial, cuando se está trabajando en un equipo de desarrollo que comparte un repositorio remoto es el siguiente:

1. Si hace tiempo que no lo has hecho, consigue la última versión del proyecto:
   • hg pull
   • hg update
2. Haz algunos cambios
3. Haz commit (localmente)
4. Repite los pasos 2-3 hasta que quieras compartir tus cambios con el resto del equipo
5. Cuando estés listo para compartir el código:
   • hg pull para obtener los cambios de otras personas (si los hay)
   • hg merge para mezclarlos con los tuyos
   • Pasar todos los tests para asegurarse de que el merge no ha estropeado nada
   • hg commit (del merge)
   • hg push

Cómo crear un repositorio Mercurial

Vamos a trabajar con Mercurial utilizando tanto la línea de comandos como el plug-in integrado en Eclipse. En ambos casos está ya todo lo necesario instalado en la máquina virtual. Vamos a comenzar utilizando la línea de comandos. Abre un terminal.

Para inicializar un directorio como un repositorio Mercurial basta con llamar al comando hg init <directorio>. Mercurial crea un fichero oculto .hginit dentro del directorio en el que guarda toda la información necesaria. A diferencia de otros sistemas como CVS o SVN, ese fichero es único y se crea en el directorio raíz del repositorio.

Vamos a usar un repositorio Mercurial por cada módulo, el espacio de trabajo en el que se guardan todos los proyectos del módulo.

1. Empezamos inicializando el espacio de trabajo workspaces/prueba como un repositorio Mercurial:

$ cd workspaces/prueba
$ hg init .
$ ls -la
total 20
drwxr-xr-x 5 expertojava expertojava 4096 2012-09-24 13:08 .
drwxr-xr-x 3 expertojava expertojava 4096 2012-09-23 11:14 ..
drwxr-xr-x 5 expertojava expertojava 4096 2012-09-23 12:52 agenda
drwxr-xr-x 3 expertojava expertojava 4096 2012-09-24 13:08 .hg
drwxr-xr-x 4 expertojava expertojava 4096 2012-09-23 12:29 .metadata

Vemos que se ha creado el directorio .hg en el que Mercurial guarda toda la información necesaria.

2. Configuramos el nombre de usuario y el editor por defecto de Mercurial. Para ello creamos el fichero .hgrc en el directorio /home/expertojava con el nombre de usuario y el editor de textos por defecto.

Fichero /home/expertojava/.hgrc:

[ui]
username = Pedro Perez <pedro.perez@gmail.com>
editor = gedit

De esta manera en todos los commits que haga mercurial se utilizará este usuario por defecto.

3. En el directorio raíz del directorio de trabajo (workspaces/prueba) creamos el fichero .hgignore con los patrones de los nombres de ficheros y directorios que queremos que Mercurial ignore y no añada al repositorio. Los patrones se aplican de forma recursiva a todos los directorios dentro del espacio de trabajo.

Fichero workspaces/prueba/.hgignore:

syntax: glob

# ficheros Java compilados
*.class

# contenidos de los directorios bin
bin/*

# configuración del espacio de trabajo de Eclipse
.metadata/*

# hg merge reject files and originals arising for reverts
*.rej
*.orig

4. Comprobamos con el comando hg status el estado de los ficheros en el espacio de trabajo. Aparecerán con una interrogación los ficheros pendientes de añadirse al repositorio (todos los no ignorados):

$ hg status
? .hgignore
? agenda/.classpath
? agenda/.project
? agenda/.settings/org.eclipse.jdt.core.prefs
? agenda/src/es/ua/jtech/pres/Main.java
? agenda/src/es/ua/jtech/pres/Tarjeta.java

Vemos que están pendientes de añadir al repositorio el fichero .hgignore que acabamos de crear, los ficheros de configuración del proyecto de Eclipse .classpath, .project y .settings y los ficheros .java

5. Añadimos ficheros y hacemos un commit con un mensaje:

$ hg add *
adding agenda/.classpath
adding agenda/.project
adding agenda/.settings/org.eclipse.jdt.core.prefs
adding agenda/src/es/ua/jtech/pres/Main.java
adding agenda/src/es/ua/jtech/pres/Tarjeta.java
$ hg commit -m "Primera versión del proyecto agenda"

6. Comprobamos que se ha realizado correctamente el commit con el comando hg log:

hg log
changeset:   0:a96f43dbae18
tag:         tip
user:        Domingo Gallardo <domingo.gallardo@ua.es>
date:        Mon Sep 24 18:06:38 2012 +0200
summary:     Primera versión del proyecto agenda

7. Comprobamos también que todo es correcto con la herramienta TortoiseHg Workbench, con la que podemos ver gráficamente los cambios que se han ido introduciendo en cada nueva versión del proyecto:

Cómo trabajar con Mercurial desde Eclipse

Vamos a ver cómo usar Eclipse para trabajar con Mercurial. En la versión de Eclipse de la máquina virtual está instalado el plug-in de Mercurial, que permite acceder a todos los comandos del sistema de control de versiones desde el entorno de programación.

1. Comprobamos que el plug-in de Mercurial está instalado y configuramos correctamente el usuario por defecto. Para ello seleccionamos la opción Window > Preferences > Team > Mercurial y nos aseguramos de que la opción Prefer 'username' value from .hgrc as default user name está marcada.

2. Para que el plug-in de Mercurial reconozca que el espacio de trabajo está siendo versioneado es necesario "indicárselo". Para ello seleccionamos con el botón derecho sobre el proyecto agenda la opción Team > Share Project y escogemos Mercurial como plug-in. Cuando seleccionamos Next aparece un mensaje indicando que se ha encontrado un repositorio Mercurial en el directorio padre (el workspace) y preguntando si queremos usarlo:

3. Pulsamos Finish y comprobamos que Eclipse añade un pequeño icono a los ficheros y proyectos que están actualizados en Mercurial:

4. Modificamos algún fichero Java. Por ejemplo, añadimos un campo llamado movil de tipo String a la Tarjeta, junto con sus getters y sus setters. Contendrá el número de móvil del contacto.

5. Comprobamos que el icono del fichero y los directorios cambian, indicando que está pendiente de ser incorporado al repositorio Mercurial:

6. Seleccionamos la opción Team > Commit para realizar un commit de los cambios. Eclipse nos muestra una ventana en la que podemos introducir el mensaje y aparece el nombre de usuario que está haciendo el commit:

7. Añadimos un último cambio en la clase Tarjeta: modificamos el método toString para que la cadena devuelta incluya también el móvil de la persona. Hacemos también un commit desde Eclipse.

8. Comprobamos en el terminal que los commits se han realizado correctamente haciendo un hg log y viendo que el historial de revisiones que se han añadido. La etiqueta tip en la última revisión indica que es la revisión actual:

$hg log
changeset:   2:4326f5c7b9b5
tag:         tip
user:        Estudiante JavaUA <domingo.gallardo@gmail.com>
date:        Thu Oct 04 13:03:24 2012 +0200
summary:     Modificado el método toString de Tarjeta

changeset:   1:3cd9456a20c1
user:        Estudiante JavaUA <domingo.gallardo@gmail.com>
date:        Thu Oct 04 12:16:44 2012 +0200
summary:     Añadido el campo "móvil" en la clase Tarjeta

changeset:   0:92d91ba4a541
user:        Estudiante JavaUA <domingo.gallardo@gmail.com>
date:        Thu Oct 04 12:12:57 2012 +0200
summary:     Primera versión del proyecto agenda

Cómo volver a una versión pasada

Una de las ventajas de usar un control de versiones es que en cualquier momento del desarrollo es posible volver a una versión pasada del proyecto. Cuando volvemos a una versión pasada, recuperamos en el disco duro el estado de todos los ficheros tal y como estaban en esa versión.

El comando de mercurial hg update -r <num-version> recupera la versión num-version.

1. Vamos a volver a la versión 0, antes de que se haya añadido el campo movil. Basta con hacer:

$ hg update -r 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Eclipse no carga automática los cambios de ficheros en el disco duro. Vemos que si pinchamos en la ventana del editor con la clase Tarjeta aparecerá el siguiente mensaje:

Decimos que sí.

Para actualizar el espacio de trabajo de Eclipse con los cambios de los ficheros en el disco duro tenemos que pulsar el botón derecho sobre el proyecto y seleccionar Refresh. Y también pulsamos Team > Refresh Status para que Eclipse actualice la versión de Mercurial.

2. Podemos también cambiar de versión desde Eclipse. Para ello pulsamos el botón derecho y la opción Team > Switch to.... Aparecerá la siguiente ventana para seleccionar la versión a la que queremos cambiar:

Seleccionamos la última versión para volver a ella.

Cómo crear una rama y hacer un merge

Vamos a hacer un pequeño ejemplo en el que creamos una nueva rama en la que vamos a añadir una clase nueva al proyecto. Después mezclaremos la rama recién creada con la rama principal.

En Mercurial cada vez que hacemos un commit creamos una versión nueva con un conjunto de cambios a partir de una versión padre. Si recuperamos una versión pasada (con update -r) y hacemos cambios a partir de esa versión tendremos dos ramas: dos conjuntos de cambios que se han realizado a partir del mismo padre. Una rama será la que ya existía y otra la que acabamos de crear. Vamos a verlo.

1. Supongamos que la versión actual del proyecto es la versión en producción y que queremos añadir una funcionalidad nueva en otra rama. En la rama de producción (etiquetada con default) añadiremos correcciones de bugs y pequeños cambios relacionados con las funcionalidades de producción. En la nueva rama añadiremos las nuevas características.

2. Empezamos por crear una nueva rama con el nombre v2.0. Para ello, desde Eclipse, seleccionamos la opción Team > Add Branch... y escribimos el nombre de la nueva rama.

Desde línea de comandos podríamos hacer lo mismo con el comando:

$ hg branch v2.0

Podemos consultar la ramas actuales del proyecto con el siguiente comando:

$ hg branches
v2.0 3:b133f5ad6e98
default 2:4326f5c7b9b5 (inactive)

3. Con esto hemos creado la rama v2.0 y la hemos convertido en activa. Todos los commits que hagamos a partir de ahora los haremos en esta rama. Vamos a añadir una nueva clase Dirección con dos campos String: calle y ciudad y sus getters y setters. En el panel de explorador de paquetes aparecerá de esta forma:

4. Hacemos commit desde Eclipse. El plug-in detecta que no hemos añadido el fichero Direccion.java y permite marcar una casilla para añadirlo. Escribimos también un mensaje en el commit, indicando que estamos comenzando una nueva rama:

5. En este momento tenemos en el repositorio dos ramas y el espacio de trabajo actual está añadiendo los cambios en la nueva rama denominada v2.0. Podemos movernos de una rama a otra haciendo hg update -r <nombre-rama> desde la línea de comandos (deberemos hacer después un Refresh y un Team > Refresh Status en Eclipse para actualizar los ficheros en el espacio de trabajo).

También podemos cambiar de rama desde Eclipse con la opción Team > Switch To... y escogiendo la rama a la que queremos ir.

6. Movemos el proyecto a la rama default:

Ahora estamos en la rama default, en lo que suponemos que es la línea de producción principal del proyecto. Vamos a corregir un supuesto bug. Nos hemos dado cuenta de que no queremos permitir que nadie (ni siquiera desde el mismo paquete) acceda a los campos. Para ello añadimos el modificador private a los campos:

public class Tarjeta {

	private int id;
	private String nombre;
	private String eMail;
	private String movil;
	
	...

7. Hacemos un commit y podemos comprobar con la herramienta gráfica TortoiseHg las dos ramas definidas:

La últimas revisiones correspondientes a cada rama se denominan cabezas (heads). Podemos consultar las cabezas actuales con el comando hg heads:

$ $ hg heads
changeset:   5:6bd10a1f8ae6
tag:         tip
parent:      2:4326f5c7b9b5
user:        Estudiante JavaUA <domingo.gallardo@gmail.com>
date:        Thu Oct 04 23:19:55 2012 +0200
summary:     Campos de Tarjeta privados.

changeset:   4:6624895275a2
branch:      v2.0
user:        Estudiante JavaUA <domingo.gallardo@gmail.com>
date:        Thu Oct 04 18:25:30 2012 +0200
summary:     Nueva rama de desarrollo v2.0: añadida la clase Dirección

8. Suponemos que ya hemos terminado el desarrollo de la rama Direccion y que queremos integrarla en la rama principal. Lo hacemos con el comando de hg merge. Desde Eclipse podemos hacerlo con la opción Team > Merge...:

Desde línea de comando hay que ejecutar hg merge para mezclar las dos ramas actuales. Después hay que hacer un commit para añadir el proyecto resultante al repositorio.

$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg commit -m "Mezclada la Direccion"

9. Por último comprobamos en TortoiseHg la evolución del proyecto:

Resolución de conflictos

¿Qué sucede si cuando vamos a hacer un merge de dos ramas Mercurial detecta un conflicto? Vamos a verlo a continuación, y vamos a comprobar también cómo resolverlo.

Pero antes debemos plantearnos qué considera Mercurial un conflicto. Supongamos que tenemos dos ramas distintas A y B que queremos mezclar. Ambas ramas han surgido de un mismo padre y contienen una serie de cambios sobre los ficheros originales. Si en la rama A un fichero no se modifica y en la B sí, no hay ningún conflicto. Si se añade o se borra un fichero en una rama y en la otra no se toca tampoco hay conflicto. Un conflicto surge en aquellos ficheros en los que en una rama se han introducido cambios incompatibles con los cambios de otra rama. Incluso podría darse el caso de que se modificara un mismo fichero en ambas ramas, cada una añadiendo algunas líneas en zonas distintas, y no se diera un conflicto porque es posible integrar esas dos modificaciones y obtener un fichero final en el que los cambios de A no colisionan con los de B (ni al revés).

En el momento en que el merge detecta un conflicto Mercurial marca los ficheros que están afectados por el conflicto. No podremos hacer un commit hasta que no hayamos marcado esos ficheros como resueltos con el comando hg resolve:

• hg resolve -l: lista los ficheros que tenían o todavía tienen conflictos. "U" = no resuelto y "R" = resuelto.
• hg resolve -m [FICHERO]: marca un fichero como resuelto (después de haberlo modificado a mano). Por defecto, sin nombre de fichero, marca todos los ficheros no resueltos.
• hg resolve -u [FICHERO]: marca un fichero como no resuelto. Por defecto, sin nombre de fichero, marca todos los ficheros resueltos.

1. Vamos a probarlo. Comenzamos creando una rama nueva (usando Eclipse, por ejemplo) a partir de la revisión actual y la llamamos "Rama con conflicto". Modificamos en ella los campos de la clase Direccion como públicos:

public class Direccion {
	public String calle;
	public String ciudad;
	
	...
}

Modificamos también la clase Main para añadir un elemento más al array de tarjetas:

...
	misTarjetas[2] = new Tarjeta(2,"rudy.fernandez@gmail.com");
	...

Hacemos commit.

2. Nos movemos a la rama default en Eclipse con la opción Team > Switch to... y cambiamos las mismas clases de antes. En la primera vamos a introducir un conflicto:

public class Direccion {
	private String calle;
	private String ciudad;
	
	...
}

En la segundo introducimos una modificación en el bucle que imprime las tarjetas, añadiendo la cadena "Tarjeta i:":

for (int i = 0; i < misTarjetas.length; i++) {
	Tarjeta tarjeta = misTarjetas[i];
	System.out.println("Tarjeta " + i + ": "+ tarjeta.toString());
}

Hacemos commit y comprobamos el estado de las ramas antes de hacer un merge:

3. Seleccionamos la opción Team > Merge... para mezclar la rama actual (default) con la rama anterior (Rama con conflicto). Aparece un mensaje de error diciendo que debemos resolver el conflicto. En el explorador de paquetes aparecen marcados en rojo los ficheros en los que hay conflictos.

Y también aparecen en un panel específico llamado Mercurial Merge:

4. Para resolver los conflictos, hacemos un doble click en el panel Mercurial Merge en cada uno de los ficheros y aparecerá una ventana de diferencias. El panel de la izquierda muestra el estado actual del fichero y el de la derecha el estado en la otra rama. Aparecerán marcados los cambios en los que se han detectado conflictos. Podamos editar a mano el fichero actual (izquierda) o pinchar en los botones centrales para pasar los cambios que nos interesan de la otra rama.

Empezamos por Direccion.java. En este caso vamos a dejar los campos como privados. No modificamos el fichero y simplemente cerramos el editor de cambios. Para confirmar que vamos a mantener el fichero debemos marcarlo como resuelto:

Abrimos después el editor de cambios en Main.java. Veremos esto:

Actualizamos la versión actual con el cambio de la tajeta nueva, y grabamos el fichero resultante. Cerramos el editor de cambios y marcamos el fichero Main.java como resuelto.

Una vez que ambos ficheros están marcados como resueltos, ya podemos hacer commit de la mezcla.

Arreglamos el problema con el límite del array y habremos terminado:

bibtbucket.org es un sitio de alojamiento de proyectos mercurial que proporciona una serie de servicios orientados al trabajo en equipo y la gestión de las versiones de los proyectos allí alojados.

Vamos a utilizar bitbucket para alojar los repositorios realizados por los estudiantes del curso y para dejar los repositorios iniciales de los proyectos de cada módulo, así como las soluciones, una vez que todos los ejercicios se hayan entregado y corregido. Utilizaremos las siguientes cuentas de bitbucket:

• Cuenta java_ua (URL: https://bitbucket.org/java_ua/): guardaremos en ella los repositorios iniciales de cada módulo que contendrán algunos proyectos y plantillas iniciales con las que comenzar a trabajar. Los repositorios tendrán el nombre <modulo>-expertojava. Por ejemplo lja-expertojava será el repositorio inicial del módulo Lenguaje Java Avanzado. Los repositorios serán privados, pero visibles a estudiantes y profesores.

• Cuentas de estudiantes: cada estudiante creará una cuenta bitbucket en la que guardará sus proyectos. En la cuenta subirá los repositorios de los módulos, conforme vaya realizando los proyectos. Le servirá como copia de seguridad de su trabajo y también para entregar los ejercicios al final de cada módulo. Para que el profesor pueda hacer la corrección del módulo, deberá tener permiso de lectura y escritura en el repositorio. El profesor realizará la corrección, añadiendo un fichero de texto con los detalles de la misma en la raíz del repositorio y, en algunos casos, modificando algunos ficheros del repositorio con anotaciones.

• Cuentas de profesores: cada profesor tiene una cuenta bitbucket que utilizará para publicar el repositorio inicial de su módulo en la cuenta java_ua y para acceder a los repositorios de los estudiantes para realizar la corrección. Los usuarios en bitbucket son los siguientes:

  • María Isabel Alfonso: https://bitbucket.org/malfonsogalipienso
  • Boyán Bonev: https://bitbucket.org/boyanib
  • Otto Colomina: https://bitbucket.org/ottocol
  • Francisco García: https://bitbucket.org/frangarcia
  • Domingo Gallardo: https://bitbucket.org/domingogallardo
  • Aitor Medrano: https://bitbucket.org/aitormedrano
  • Miguel Ángel Lozano: https://bitbucket.org/malozano
  • Alejandro Such: https://bitbucket.org/alejandro_such
  • José Luis Zamora: https://bitbucket.org/jlzamoras

Cómo crear una cuenta en Bitbucket

Es un servicio externo al curso, y todos los estudiantes deben crearse una cuenta siguiendo los siguientes pasos:

1. Entra en https://bitbucket.org/account/signup/ e introduce tus datos:

2. Una vez que hayas creado la cuenta, envía una notificación de bitbucket a java_ua para que añadamos tu usuario al grupo Estudiantes:

3. Cuando te demos de alta en el equipo java_ua deberás poder tener acceso de lectura a los repositorios en https://bitbucket.org/java_ua. En tu página, puedes pinchar en la opción Dashboard poder ver todos los repositorios a los que tienes acceso y los equipos en los que participas. Debes tener acceso a los repositorios iniciales de los módulos Presentación (pres-expertojava) y Lenguaje Java Avanzado (lja-expertojava):

Cómo subir un repositorio a bitbucket

1. Crea en bitbucket el repositorio prueba en bitbucket

2. Sube el repositorio Mercurial de tu disco duro a bitbucket, con el comando hg push y la URL de bitbucket que acabas de crear:

$ hg push https://estudiante_javaua@bitbucket.org/estudiante_javaua/prueba
pushing to https://estudiante_javaua@bitbucket.org/estudiante_javaua/prueba
http authorization required
realm: Bitbucket.org HTTP
user: estudiante_javaua
password: 
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 7 changesets with 10 changes to 7 files
remote: bb/acl: estudiante_javaua is allowed. accepted payload.

3. Una vez subido, podrás utilizar la interfaz web de bitbucket para explorar el repositorio. Podrás ver el código fuente de la versión actual, comprobar los cambios que se han añadido, etc. Por defecto el repositorio es privado y sólo tú tienes acceso a él.

4. Puedes evitar tener que escribir la URL del repositorio remoto añadiendo el repositorio push por defecto en el fichero .hg/hgrc:

[paths]
default-push = https://estudiante_javaua@bitbucket.org/estudiante_javaua/pres-expertojava

5. Prueba a hacer algún cambio en el proyecto, hacer un commit y después ejecuta hg outgoing para comprobar los cambios que se van a subir:

$ hg outgoing
comparing with https://estudiante_javaua@bitbucket.org/estudiante_javaua/prueba
http authorization required
realm: Bitbucket.org HTTP
user: estudiante_javaua
password: 
searching for changes
changeset:   7:ca7add626ee5
tag:         tip
user:        Domingo Gallardo <domingo.gallardo@ua.es>
date:        Wed Sep 26 07:18:17 2012 +0200
summary:     Un pequeño cambio para probar el push

6. Por último haz hg push para subir los cambios al repositorio de bitbucket:

$ hg push
pushing to https://estudiante_javaua@bitbucket.org/estudiante_javaua/prueba
http authorization required
realm: Bitbucket.org HTTP
user: estudiante_javaua
password: 
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: bb/acl: estudiante_javaua is allowed. accepted payload.

Comprueba que en la web de bitbucket que el repositorio remoto se ha actualizado.

Cómo descargar el repositorio inicial de un módulo

Para cada uno de los módulos del Experto vas a poder descargarte su repositorio inicial, que contiene algunos proyectos iniciales o plantillas que utilizarás como punto de partida para completar los ejercicios y trabajos. Estará disponible en la cuenta de bitbucket java_ua al comienzo de cada módulo.

Deberás utilizar el comando hg clone para obtener el repositorio inicial. Una vez clonado, el repositorio estará en tu disco duro local y trabajarás con él como hemos hecho con el repositorio prueba. Deberás subirlo a tu repositorio remoto privado en bitbucket para tener una copia de seguridad y, posteriormente, entregarlo para que lo corrija el profesor.

Vamos a ver un ejemplo en el que explicamos paso a paso cómo empezar a trabajar con el repositorio inicial del módulo Presentación.

1. Verás que en tu página de bitbucket, en el apartado Dashboard tienes un enlace a los proyectos existentes en java_ua. Pincha en el proyecto java-ua/pres-expertojava y para acceder página bitbucket del repositorio. Puedes verlo porque tienes permiso de lectura en java_ua. En esa página puedes consultar el código fuente del proyecto inicial y aparece la dirección y el comando hg clone que debes utilizar para descargarlo.

2. Vamos a clonar el repositorio inicial en el directorio workspaces/pres. Aunque el nombre del repositorio remoto y el del local podrían ser distintos porque funcionan únicamente como contenedores vamos a utilizar el mismo nombre por defecto. Desde línea de comando, nos colocamos en el directorio workspaces y ejecutamos el comando hg clone. El comando crea el nuevo directorio y se descarga en él el repositorio remoto:

$ hg clone https://estudiante_javaua@bitbucket.org/java_ua/pres-expertojava
http authorization required
realm: Bitbucket.org HTTP
user: estudiante_javaua
password: 
destination directory: pres-expertojava
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 5 changes to 5 files
updating to branch default
5 files updated, 0 files merged, 0 files removed, 0 files unresolved

Ahora el repositorio local está conectado al repositorio remoto en bitbucket.org/java_ua. Debes conectarlo a tu propio repositorio remoto en bitbucket.

3. Primero crea en tu cuenta de bitbucket un repositorio vacío con el mismo nombre que el que te has descargado:

4. Ahora modifica el fichero .hg/hgrc y cambia la dirección de push por defecto a la de tu propio directorio en bitbucket:

[paths]
default = https://estudiante_javaua@bitbucket.org/estudiante_javaua/pres-expertojava

5. Haz un hg push para subir el proyecto a tu repositorio bitbucket:

$ hg push
pushing to https://estudiante_javaua@bitbucket.org/estudiante_javaua/pres-expertojava
http authorization required
realm: Bitbucket.org HTTP
user: estudiante_javaua
password: 
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 5 changes to 5 files
remote: bb/acl: estudiante_javaua is allowed. accepted payload.

6. Abre un nuevo workspace de Eclipse en ese directorio:

7. Y por último carga los proyectos iniciales en el espacio de trabajo con la opción Import... > Existing Projects into Workspace:

Puedes comprobar que Eclipse ha reconocido que el proyecto se encuentra en un repositorio Mercurial.

8. Prueba a ejecutar el programa. Verás que se abre un panel gráfico en el que puedes pinchar para pintar un punto. Por último, modifica el código para que en la salida estándar aparezcan las coordenadas x e y en las que se dibuja el punto.

9. Termina haciendo un commit desde Eclipse y haciendo un hg push para subir los cambios a tu repositorio remoto. Comprueba en la web que todo está correcto.

Cómo bajar nuevos proyectos del repositorio inicial

Es posible que durante el transcurso del módulo el profesor suba algún proyecto nuevo al repositorio inicial.

1. Para actualizar nuestro repositorio con el proyecto nuevo basta con utilizar el comando hg pull seguido de la URL del repositorio en java_ua:

$ hg pull https://estudiante_javaua@bitbucket.org/java_ua/pres-expertojava
http authorization required
realm: Bitbucket.org HTTP
user: estudiante_javaua
password: 
pulling from https://estudiante_javaua@bitbucket.org/java_ua/pres-expertojava
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 4 changes to 4 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

2. Las modificaciones que se han descargado constituyen una rama nueva del proyecto. Lo comprobamos explorando el repositorio con TortoiseHg o con el comando hg heads:

$ hg heads
changeset:   3:22150ac53bb7
tag:         tip
user:        Domingo Gallardo <domingo.gallardo@ua.es>
date:        Wed Sep 26 16:33:19 2012 +0200
summary:     Nuevo proyecto

changeset:   1:2e5d650a8f3b
user:        Estudiante JavaUA <estudiante_javaua@gmail.com>
date:        Wed Sep 26 16:12:45 2012 +0200
summary:     Imprime las coordenadas del punto

3. Hacemos un hg merge y un hg commit para unir las ramas:

$ hg merge
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg commit -m "Traido nuevo proyecto"

Y por último subimos los cambios a nuestro repositorio en bitbucket:

$ hg push
pushing to https://estudiante_javaua@bitbucket.org/estudiante_javaua/pres-expertojava
http authorization required
realm: Bitbucket.org HTTP
user: estudiante_javaua
password: 
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 4 changes to 4 files
remote: bb/acl: estudiante_javaua is allowed. accepted payload.

Cómo realizar la entrega de ejercicios de un repositorio

1. Cuando hayas terminado todos los ejercicios y vayas a hacer la entrega debes etiquetar la última versión con la etiqueta entrega:

$ hg tag entrega
$ hg push

2. Para que el profesor pueda corregir el repositorio deberás añadirlo con permiso de escritura. Selecciona la pestaña Admin en el repositorio, pincha en Access Management y añade al profesor con permiso de escritura:

3. Y para notificar la entrega, envía un mensaje al profesor desde el correo de bitbucket: