Tag Archives: Eclipse

El lamentable estado de las herramientas de desarrollo Android

Advertencia: si le tienes mucho cariño a Google, mejor que no sigas leyendo. Si desarrollas Apps como es mi caso (para iOS y Android) y no tomas como dogma de fe todo lo que dice Google (ni Apple, ni Microsoft, ni nadie), adelante.

Segunda advertencia: leed el update de abajo del todo, por favor. Para que os hagáis una idea de lo grave que es este asunto…

Ahora mismo estamos en pleno Google I/O, la conferencia para desarrolladores de Google. Se están presentando muchas novedades de consumo, lo que me parecen muy bien. Hay incluso un nuevo lenguaje visual llamado Material (que, por desgracia no veremos mas que en los Nexus, ya que los fabricantes se lo van a cargar; y aún así habrá que ver en qué Nexus y cuándo).

Todo muy bien, pero ¿qué pasa con las herramientas de verdad para desarrolladores?

Estas herramientas, no nos engañemos, son: el compilador, el lenguaje y el IDE. Eso es lo que usamos el 90% del tiempo mientras desarrollamos Apps. Pues parece que, en 2014, todo sigue como en 2013. En la edad de la piedra. En el más absoluto desprecio de Google hacia sus desarrolladores.

Sí señores: desprecio. No es de recibo las herramientas que proporciona Google, insisto, en 2014. Revisemos.

El lenguaje de programación

Es Java. Ni creado ni controlado por Google. Conste que no odio Java (he invertido mucho tiempo en aprenderlo y certificarme como para no tomarle cariño). Pero seguir en Java 6 cuando ha salido Java 8 con un montón de novedades interesantes me escuece. Mucho. Quiero esos tipos opcionales, clausuras y funciones de primer orden. En Android. Y lo quiero ya. Llámame caprichoso, pero creo que ya toca avanzar.

Seguir con esta versión de Java se debe seguramente al litigio que Oracle le está ganando a Google sobre la copia de Java para la máquina virtual Dalvik. Es ese el motivo de aguantar mientras puedan con Dalvik, cambiar a ART (el runtime que se va a usar a partir de ahora) y en cuanto puedan (probablemente la I/O de 2015) presentar el desarrollo de Android con Go. Que es un lenguaje creado por Google. Lo cual, por cierto, tampoco me disgustaría.

El cambio de Dalvik por ART no se debe a que incorpore 64 bits. Ni a que sea más óptimo. Si Dalvik es ya abierto ¿por qué no incorporar esas novedades y mejoras en la máquina virtual que ya tienen todos los Android? Probablemente por huir de un barco que se hunde. Y además: ¿para qué darle a todos los que están haciendo clones de Android (Nokia X, Amazon, Barnes & Noble Nook, Aliyun) estas mejoras? Me juego algo a que al final ART sólo lo podrán usar los miembros de la Open Handset Alliance. ¿Open?

IDE

Controlar el lenguaje es algo importante para crear un buen ecosistema de desarrollo. Microsoft creó C#, escribe su runtime, compilador y tiene el que probablemente sea el mejor IDE de todos: Visual Studio. Apple escribe su propio IDE, Xcode, que es una maravilla (como editor es mejorable y le faltan refactors, pero en Xcode se pueden hacer cosas que Eclipse no hará en la vida y Android Studio dentro de 100 años; ante las dudas ver un Storyboard, el diseñador de efectos de partículas con SpriteKit, los PlayGrounds de Xcode 6 o los Gauges). Apple influye poderosamente en el compilador, llvm, hasta el punto de haber creado un nuevo lenguaje de programación (Swift) para avanzar tras usar casi en exclusiva Objective-C los últimos 20 años.

Google, por contra, empezó creando un plugin de Eclipse para añadir algunos refactors, un asistente aquí y allá, un visualizador del XML de los layouts y poco más. Eclipse ni es de Google, ni Google puede influir en su desarrollo para hacerlo más Android. Luego, esperaron a que la comunidad demostrase que IntelliJ Idea era una alternativa viable para el desarrollo Android y propusieron Android Studio con mucho bombo y platillo… en Mayo de 2013. Es casi Julio de 2014 y seguimos con una herramienta en versión Alpha, que no ha alcanzado aún la versión 1.0.

Excusas

No, no me valen excusas sobre «es que Google ya se sabe, pone las cosas en Beta y tal». Google no es una startup montada por cuatro chavales. Es la compañía más valiosa del planeta. Tienen pasta y tienen cerebros. Lo que no tienen es ningún interés en mejorar las herramientas de desarrollo.

Google sólo se preocupa de aquellos productos en los que puede vender su publicidad. Todo lo que no sirva para imprimir anuncios, sigue el camino de Google Reader y del Dodo. Y como no pueden imprimir anuncios mientras compilas, tenemos lo que tenemos.

Modelos de negocio distintos

Hay que entender el modelo de negocio de cada una de estas tres empresas para comprender cómo actúan:

  • Microsoft quiere venderte licencias. Por eso hacen el software que hacen, sólo para Windows, porque quieren venderte las licencias de Visual Studio, Team Foundation Server y Windows. Lo tomas o lo dejas, pero son claros.
  • Apple quiere meterte en su ecosistema y venderte chismes, que es donde ganan pasta, no con software (que ahora lo dan gratis, desde el S.O. hasta Xcode pasando por la suite ofimática). Ellos quieren que te compres un iPad, un iPhone, un MacBook Pro retina con AppleCare y que sigas y sigas comprando sus productos. Hacen buen software para apoyar la venta de sus productos hardware.
  • Google vende publicidad. Es con lo que gana dinero. No es nada innoble ni lo de que avengonzarse, pero todo esto de ir de salvapatrias de los open y darse aires de ir curando el cáncer cuando lo que hacen es espiarte para vender mejores anuncios me resulta muy gracioso. Google nunca ha sido pro software libre.

Open no es Libre

Open no significa nada y me molesta el uso torticero que Google hace de este término. No dicen libre porque se le echaría encima todo el mundo del Software ídem, dicen open como en voy a tirarte las migajas de los repositorios de código fuente de Android para que veas lo bueno que soy.

Eso no es libre.

En un proyecto Software Libre se puede ver el código mientras se desarrolla, y no después. Se puede aportar código. Es una meritocracia.

Aquí tenemos un desarrollo totalmente propietario y cerrado creado por una compañía que libera código al terminar. Y, por cierto, sólo parte de ese código. Google Maps o Gmail no lo liberan. Ahí lo open no entra, que eso es parte de mi maquinaria de vender anuncios… Llevo usando, aportando y tratando de comprender a la comunidad del Software Libre desde el 94. Me molesta que la gente se confunda y crea que Google nos defiende de las «Megacorporaciones» como Microsoft o Apple. Como si ellos fueran Teresa de Calcuta.

Las tres son iguales: compañías que tratan de imponer sus productos en el mercado. Ninguna tiene como misión salvar al mundo. No le demos más vueltas.

Gradle

Así que para poner la guinda al pastel, tras usar un lenguaje que no es suyo y ofrecerte dos IDEs que tampoco hacen, han cambiado a Gradle, un sistema de construcción que tiene muy buena pinta, pero que de salida es muuuucho más lento que Ant. Es decir: tu proyecto en Eclipse compila más rápido que en Android Studio. Que sí, que se puede acelerar Gradle. Entonces ¿por qué no viene de salida ya configurado correctamente? ¿Por qué machacar a los devs que ya tenemos bastante al migrar un proyecto de Eclipse a AS? Es en estas cosas donde veo la desidia de Google.

Y ese es el meollo de la cuestión. Que el equipo de desarrollo de AS en Google deben ser un programador y un becario. Y el becario a tiempo parcial. Sólo así se puede explicar el ritmo de no-avance de la herramienta. De nuevo, sin excusas: si Apple puede en un año sacar una nueva versión de Xcode, digo yo que Google podrá. Pero claro, si pierdes el foco creando gafas, relojes, coches, drones y mil cosas más pero no vas a lo fundamental pasan estas cosas.

Costes

Y ahora es cuando alguien pensará: «ya, pero es que en Apple hay que pagar 80 € anuales y en Microsoft el Visual Studio de verdad cuesta pasta, mientras que en Google pagas una vez en la vida 25 dólares y ya».

Efectivamente: ¿ves una tendencia?. Pagas por un producto == calidad. No pagas y no pueden ponerte publicidad == Google Reader, digo herramientas de desarrollo.

Tú es que eres un Fanboy de Apple

Vaaaale, venga, sí, soy un Fanboy de Apple. Los tiempos de compilación de Gradle me los invento. Y tener un IDE más de un año en Alpha es de lo más normal. O que para lanzar el emulador tengamos que andar con trucos como la aceleración Intel o usar Genymotion (de nuevo, nada de esto de Google). De paso, que nada de lo que usa Google Play Services (que cada vez son más cosas) no funcione en el emulador y tengamos que tirar de dispositivo también es un triunfo.

Quizá tu problema es que no has tratado de desarrollar con otro entorno que no sea Android Studio. En mi caso, sí. Uso Xcode, Eclipse y Android Studio a diario. Y antes usé Visual Studio, Aptana, Delphi, Turbo C y vim. ¡Hasta Blackberry ha hecho un mejor trabajo con Eclipse para BB10 que Google!

Creo que hablo con cierto conocimiento de causa. Pero si tienes argumentos en contra de algo que lo que digo (que no sean es que a mi me gusta más X en lugar de Y) sino cosas como «resulta que el roadmap de Gradle muestra que Z y Android Studio se puede mejorar de tal y cual forma» bienvenidos sean. Si quieres ponerme a parir, no comentes: escribe un post en tu propio blog. Gracias.

Y, por cierto ¿en qué parte de I/O se está hablando de las mejoras del lenguaje, IDE o compilador, más allá de ART?

Pues eso.

Actualización del 1 de Julio, 2014

Escribí esta entrada en el avión, mientras me dirigía al GCTIC a impartir unos talleres, uno de ellos de Android. El día antes tuve la precaución de copiarme el ADT Bundle que proporciona Google para todas las plataformas, por si alguien no lo tenía instalado. Tuve que usarlo: algunos de los asistentes no lo tenían instalado, y se lo proporcioné. Total, es descomprimir un ZIP en el que va Eclipse y el SDK. Es tan sencillo, que incluso escribí en este blog cómo crearte tu propio entorno de desarrollo Android portable con Eclipse.

Pues no. No era tan sencillo. Nada funcionaba. Lo instalé en mi máquina con cierta sonrisa de desdén pensando «novatillos…». Y no. No funcionaba. Ningún ADT Bundle funcionaba. Ni en Mac, ni en Windows, ni en Linux. Pensé que estarían mal descargados y empezamos a bajarlos de nuevo. Hasta que nos dimos cuenta de que la culpa era de Google:

En la página oficial de descargas del ADT Bundle han colgado versiones que no funcionan

Y no avisan. A día de hoy puedes seguir bajándote una versión rota de ADT Bundle de la página de Google. Y sabiéndolo, no la quitan de en medio ni ponen un aviso. No. Juegan con tu tiempo. ¿Tienes una entrega de una App? Me da igual. ¿Vas a impartir un taller? No me importa. Soy Google, la prepotencia con patas, y me importa [inserta aquí un adjetivo colorido] mi comunidad de desarrolladores. Ellos son muy listos, que se busquen la vida. Total, la culpa es suya por fiarse de mi página oficial de descargas.

Eso sí, en su bug tracker sí que parece que lo saben. Y dicen que lo arreglarán en uno o dos días. Después de una semana.

Estoy harto.

j j j

Borrar un AVD que se niega a morir

Al intentar borrar un AVD (la configuración de un emulador de Android, conocido como Android Virtual Device) me he encontrado con este mensaje:

AVD no se puede borrar

En este caso, he tenido claro desde el principio cual era el problema sin consultar con StackOverflow. Había lanzado ese AVD antes y se había colgado. Y pensé que seguramente había dejado algún fichero indicando que el emulador estaba en marcha, y por eso ahora al intentar borrarlo pensaba que seguía encendido.

Nada que un poco de Terminal no pueda arreglar. Debemos ir, en una terminal, a la carpeta .android/avd que está dentro de nuestra carpeta $HOME. En mi caso, como mi usuario es dfreniche, la carpeta está en la ruta:

/Users/dfreniche/.android/avd/

Para llegar a ella, usamos a nuestro viejo amigo cd:

cd /Users/dfreniche/.android/avd

Una vez allí, veremos una carpeta por cada AVD que tengamos creado en Eclipse. Si hacemos ls:

Tesla:avd dfreniche$ ls -al
total 24
drwxr-xr-x   8 dfreniche  staff  272 22 ago 12:58 .
drwxr-xr-x  17 dfreniche  staff  578 19 ago 19:41 ..
drwxr-xr-x  12 dfreniche  staff  408 22 ago 12:58 Intel.avd
-rw-r--r--   1 dfreniche  staff  114 22 ago 12:58 Intel.ini
drwxr-xr-x  11 dfreniche  staff  374 20 ago 06:48 Nexus4.avd
-rw-r--r--   1 dfreniche  staff  116 19 ago 19:32 Nexus4.ini
drwxr-xr-x  10 dfreniche  staff  340 22 ago 11:22 Nexus4_API4.3.avd
-rw-r--r--   1 dfreniche  staff  130 20 ago 06:47 Nexus4_API4.3.ini

Podemos ver que los terminados en .avd son carpetas (en los atributos empiezan con una d de directory) mientras que los .ini son ficheros normales.

Si entramos en el AVD problemático (en este caso, Intel.avd) con un cd Intel.avd y hacemos ls veremos unos cuantos ficheros sospechosos acabados en .lock.

Tesla:Intel.avd dfreniche$ ls
cache.img       hardware-qemu.ini.lock  userdata-qemu.img.lock
cache.img.lock  sdcard.img      userdata.img
config.ini      sdcard.img.lock
hardware-qemu.ini   userdata-qemu.img

Con borrar estos ficheros, basta: rm *.lock

Tras esto, Eclipse nos dejará borrar tranquilamente el AVD desde su interfaz:

AVD arreglado para ser borrado

AVD arreglado para ser borrado

j j j

Acelera el emulador de Android

«El Emulador de Android es lento». Mucho. Es una de las quejas recurrentes que tenemos los que tenemos que desarrollar para Android, bien sea por afición, devoción u obligación. Comparado con el simulador de iOS, el Emulador de Android es una tortuga. Pero claro, la comparación no es justa: Android emula un teléfono completo, con su CPU, GPU, memoria, tarjeta SD, etc. Está ejecutando código real que podríamos instalar en un teléfono, compilado para una CPU de una arquitectura que no tenemos en el escritorio (como es ARM p.ej.). El simulador de iOS crea un ejecutable x86 que «simula» comportarse dentro de un teléfono, pero realmente es un programa de Mac «travesti». La fidelidad no es la misma.

Por eso, en teoría el desarrollo con el Emulador de Android debe ser más sencillo, al tener una mejor herramienta con la que probar. Eso, si eres capaz de aguantar el tiempo insoportable que tarda en arrancar. Y si no se desconecta de adb (Android Debugger Bridge) y tienes que reiniciarlo.

HAXM

Para mejorar esto, Intel pone a nuestra disposición HAXM (Hardware Accelerated Execution Manager). Gracias a este programa, instalaremos una capa de aceleración para el Emulador de Android, que realmente se ejecuta en como una máquina virtual qEmu. qEmu es un emulador de CPUs, es decir, nos permite ejecutar en nuestros equipos basados en Intel x86 (como un Core i5 por ejemplo) S.O. que corren en Intel (como Windows, Linux, Mac) o bien otros S.O. que necesitan otras CPUs y arquitecturas (como es el caso de Android con ARM).

HAXM es un driver (o un módulo del kernel en Linux / extensión del kernel en Mac) que concede a qEmu acceso directo al hardware en el que se ejecuta. Eso sí, como es un programa de Intel, sólo funciona con las CPUs Intel. Vamos, que si tu máquina tiene una CPU AMD ya puedes ir cerrando el post. Además, la CPU debe soportar VT-x (las modernas lo soportan, no pruebes con un Pentium II). Puedes consultar los requisitos en la página detallada de Intel sobre cómo instalar HAXM.

Instalación de HAXM

Si estás usando el nuevo ADT Bundle (es decir, el Eclipse + plugin ADT + SDK Android que ha sacado hace poco Google, que ya era hora por cierto) y abres el Android SDK Manager, al final encontrarás un grupo llamado «Extras» en el que está el Intel x86 HAXM Emulator Accelerator. Si estás en Windows / Linux, bájatelo desde aquí. Si estás en OS X Mountain Lion 10.8.2 no te lo bajes desde aquí, debes ir a la página de descargas de HAXM, ya que existe un bug que hará que tu querido Mac se cuelgue. Sí, has leído bien: los Macs también se cuelgan. Cuando te lo bajes, ya sea desde el SDK Manager o a mano (por cierto, en el enlace anterior están las versiones de Linux y Windows de HAXM) debes instalarlo.

En el caso del Mac, bajas un DMG que al montar te muestra un programa de instalación. Tras instalarlo (no exige reiniciar) podemos confirmar que está en funcionamiento escribiendo en una Terminal:

$ kextstat | grep haxm

Debe aparecer algo como esto:

Tesla:~ dfreniche$ kextstat | grep haxm
115  0 0xffffff7f81e29000 0x13000 0x13000  com.intel.kext.intelhaxm (1.0.4)

Si te has bajado el paquete usando el SDK manager, puedes encontrar el programa de instalación en $SDK_HOME/extras/intel/

Uso de HAXM

Una vez instalado HAXM, debemos descargar las imágenes de Android que también nos proporciona Intel. La idea es que en lugar de acelerar un emulador ARM (que sería muy complicado) Intel nos da Android para Intel Atom. De esta manera, cuando qEmu ejecuta instrucciones en el Intel Atom emulado realmente se pasan a nuestra CPU directamente, con la consiguiente mejora en rendimiento.

Estas imágenes aparecen como «Intel x86 Atom System Image» en el SDK Manager. A bajarlas. No las tenemos para todos los API levels, pero sí para los más usados (API 10, 15 y 17 y supongo que en breve sacarán para el 18).

SDK Manager mostrando las imágenes Intel ya instaladas

Ahora tendremos que crear una definición de AVD que utilice esta imagen de Intel. En lugar de un emulador con CPU ARM, vamos a escoger uno con CPU Intel Atom. De cara a nuestros programas da igual, ya que a fin de cuentas se van a ejecutar en la máquina virtual Dalvik. Si vamos a probar código Android nativo (escrito en C con el NDK) entonces lo mejor es leer la documentación de HAXM.

Creando un AVD con CPU Intel seleccionada

Cuando arranquemos nuestro AVD notaremos dos cosas. En la consola debe aparecer un mensaje que indique que «HAX is working» y casi sin darnos cuenta nuestro Emulador estará operativo. Se acabó el arrastrarse. Yo ni marco que arranque de un snapshot porque es tan rápido que no me merece la pena.

Bonus level

Si usas API level 15 ó 17 puedes usar la aceleración de hardware de la GPU, lo que hará que todavía sea más rápido. Avisado quedas de que puede no funcionar (el emulador se vería en negro y tendrías que cerrarlo). Consulta el apartado de aceleración de la GPU de la documentación Emulador para más detalles. Para activarla, marca el checkbox «Use host GPU» en la definición del AVD.

Ultra bonus level

Y si necesitas un emulador de Android «en la nube», para probar algo o mostrar en una visita a un cliente, y no tienes tu máquina pero te puedes bajar el APK de Dropbox, mira Manymo. Si con esto no te pones palote…

j j j

Instalar el plugin de Mercurial en Eclipse

Los sistemas de control de versiones son adictivos. No puedes probarlos, porque luego no puedes vivir sin ellos. Aunque sea un pequeño ejemplo el que vas a programar, te sientes perdido sin tu repositorio y empiezas a pensar «¿y si se me ocurre cambiar esto o lo otro, y luego me arrepiento?». Ese tipo de «problemas» se solucionan casi en el acto con un VCS. Y si es distribuido (Git o Mercurial), mejor que mejor.

Antes de seguir, quiero dejar claro que no entro en las guerras religiosas entre los DCVS Git o Mercurial. Yo uso Mercurial porque Joel Spolsky lo explica de forma increíblemente sencilla. Aunque ahora que Git viene integrado con XCode4, probablemente es una buena alternativa… bueno, no :-). En fin, usa el que te de la gana, pero usa uno.

Para casi todos mis proyectos uso Mercurial. No lo uso para los ejemplos que escribo para mis cursos. Y estaba pensando «¿porqué no usarlo?». Por pereza mental, y por hacer siempre las cosas de la misma forma. Mi padre dice que «si un burro tira de una noria para un lado y le das la vuelta, ya no sabe tirar de ella». Y es que nos acostumbramos a hacer siempre lo mismo, de la misma forma, y nos estancamos. De vez en cuando hay que revisarlo todo con una mirada fresca y en lugar de pensar «¿hay una manera de optimizar esto que estoy haciendo?» debemos plantearnos «¿en serio tengo que seguir haciendo esto?».

El caso es que un sistema de control de versiones es casi perfecto para dar clases. Puedes tener una primera versión, sencilla, y luego ir promoviendo a las distintas versiones más avanzadas, que pueden ser changesets o bien nuevas ramas. Los cambios que hagas durante la clase para demostrar algo siempre puedes revertirlos sin problemas. Para eso está el DCVS. Y distribuir el código es más sencillo: compartes tu repo, y los alumnos se clonan los repositorios y punto. No hay que andar con historias de copiar los Workspaces de Eclipse y que luego falle (los WS de Eclipse dependen del sistema en el que los uses, hay que cambiar luego los Build Paths, etc.). Como se puede ver, todo son ventajas. La pregunta es porqué no lo he usado hasta ahora…

Instalar Mercurial

Evidentemente, antes de nada lo primero es instalar Mercurial, ya sea para Linux, Windows o Mac, o para donde vayas a usar el DCVS. Si no, el plugin de Eclipse no podrá usar Mercurial porque no lo encontrará en tu sistema. Te lo bajas de su sitio web oficial.

Instalando hgEclipse

HgEclipse es un plugin para Eclipse que añade soporte Mercurial a tus proyectos. Una vez instalado, en el menú contextual del proyecto encontrarás en la opción Team > Share la parte de Mercurial. Para instalarlo, iremos a Help > Install New Software e introduciremos el repositorio http://cbes.javaforge.com/update. En mi caso (instalándolo en Mac) no necesito los binarios de Mercurial para Windows, así que no los marco para instalar.

Instalando hgEclipse: repositorios

Instalando hgEclipse: repositorios

Cuando pulsemos Next, pasaremos a descargar e instalar el plugin. Al final no hay más remedio que reiniciar Eclipse. Así que hazlo 🙂

hgEclipse instalándose

hgEclipse instalándose

Usando HgEclipse

Una vez con todo instalado, lo primero es crear el repositorio Mercurial en nuestro proyecto. Eso lo prepara todo para poder gestionar las versiones de tu codigo fuente. Equivale a un «hg init». Para ello, pulsaremos con el botón derecho del ratón en el nombre de nuestro proyecto y seleccionaremos Team > Share Project. Si todo está correctamente instalado nos aparecerá una ventana como la siguiente:

Share > Project

Share > Project

Como queremos crear un repo Mercurial, basta con pulsar siguiente. Nos mostrará dónde va a crear el repositorio (que es una carpeta llamada .hg, dentro de nuestra carpeta de proyecto). Aparecerán unos nuevos iconos en las carpetas y ficheros de nuestro proyecto y la palabra [new] indicando que el repo es nuevo, pero aún no se ha realizado el primer commit.

Repositorio tras el init

Repositorio tras el init

¡Vamos a añadir ficheros a nuestro repositorio! Botón derecho en el proyecto > Share Project, pero ahora aparece un menú con un montón de opciones. Seleccionamos Add. Esto añade los ficheros del proyecto al repositorio. Yo suelo añadir únicamente el código fuente, pero no los ajustes del proyecto, ni las carpetas propias de Eclipse, como muestro a continuación:

Añadamos ficheros al repo!

Añadamos ficheros al repo!

Ahora que hemos añadido, los iconos de los ficheros fuente cambian y tienen un «+» azul al lado. Están ya controlados por el repositorio, pero no hemos subido este cambio, que en este caso es subir la primera versión. Para ello, Team > Share Project > Commit y añadimos un mensaje de commit. HgEclipse nos muestra los ficheros que va a subir, y los que no tiene «controlados», por si queremos añadirlos.

Commit

Commit

Al pulsar OK, ¡listo!. Ya tenemos control de versiones funcionando. Ahora, si modificamos un fichero se nos mostrará como cambiado y podremos hacer un commit con esos cambios. O podremos compartir el código fuente del proyecto por la red con la opción Serve. Cualquiera en la red podrá hacer un Pull del repo y bajarse este código fuente. Mucho más rápido que compartir el proyecto en una carpeta SMB y encima evitas problemas con las configuraciones de Eclipse (yo lo uso en Mac y mis alumnos, normalmente, en Windows)

Las opciones del menú de Share Project son muy amplias. Os animo a irlas probando y a aprender Mercurial entre todos. El que tenga un truco especial de cómo usa Mercurial, ya sabe, que use los comentarios.

hg commit -m "post acabado"
hg tag -m "v1.0"
j j j