[#TFS2012] Hasta donde llegan los workspaces locales?

Buenas,

ok, día de asesinar con dolor el ordenador mientras volvemos a instalar Office 15. Pero para matar el tiempo, cerraré alguna de las ideas que surgieron en una conversación de twitter ayer con @jc_quijano @pablonete @luisruizpavon. La cuestion era hasta donde podemos llegar con los nuevos Workspaces locales que se han inlcuido en Visual Studio 2012 y Team Foundation Server 2012.

Vamos con un poco de historia primero. El concepto de Workspace local nace para poner fin al infierno del modo offline que tenemos con TFS hasta la versión 2010. Si bien es cierto que el modo offline ha mejorado mucho en TFS2010, el control de archivos modificados y otro tipo de acciones se sigue realizando a través de atributos de File System. El mejor ejemplo, es que los archivos “no modificados” están marcados “Read Only” y si quieres modificarlos en un modo offline, pues toca sacar este atributo, modificar y cruzar los dedos para que cuando vuelvas a conectar con TFS te reconozca los cambios. Escenarios “más complejos” como por ejemplo, renombrar un archivo requieren realizar rituales poco convencionales para poder meter estos cambios en TFS. (no hablo de sacrificar a una virgen albina en un día de eclipse sobre una estrella de 7 puntas, pero es casi igual de complicado).

Pues bien, los amigos de Redmond decidieron que era hora de poner fin a este sufrimiento y en TFS2012 han cambiado completamente el modelo. Veamos un ejemplo. La siguiente imagen muestra la configuración de un workspace llamado “W8RC-BRUNOC-LOCAL” que es de tipo LOCAL. Además todo el source control del team Project que utilicé para el webcast de team foundation service, pues se mapea a la ruta [C:\srcElBrunoLocal].

En esta ruta nos encontramos con que además de las carpetas propias del Team Project tenemos una carpeta de sistema llamada [$tf] que es la que almacena los cambios que realizamos para luego compararlos con los estados iniciales y poder sincronizar con el servidor de TFS.

Aclaración: Si bien a primera vista esto es muy parecido al comportamiento que tiene subVersion, pues solo coincide que hay una carpeta con cambios, nada más.

Pues bien, ¿qué podemos hacer ahora? pues si nos desconectamos de nuestro servidor Team Foundation Server 2012 y vemos las propiedades de una clase dentro de este workspace local, veremos que … … … por fin!! los archivos no están marcados como ReadOnly.

Es más, si editamos este archivo con el notepad y abrimos Visual Studio 2012. Aunque estemos desconectados de TFS, en el panel del Team Explorer podremos realizar algunas acciones offline:

En la vista de Pending Changes veremos como este archivo se muestra como editado.

Y ahora, llegamos hasta el objetivo de este post: ¿qué podemos hacer en este punto cuando trabajamos con workspaces locales?.

• NO podemos hacer checkIn en modo local
• Podemos comparar los cambios que hemos realizado con la versión original del archivo del workspace o la última versión
• Podemos realizar un Annotate
• Podemos deshacer los cambios que hemos realizado
• Podemos ver el histórico del archivo

Aclaración: cuidado con esta ultima opción, me la reservo para un próximo post

Ayer la conclusión fue bastante clara en el tweet

Pero esto abre una puerta a muchas suposiciones, por ejemplo la de que Ms está trabajando en un SCM distribuido como GIT o Mercurial y que lo podría incorporar en próximas versiones. Por ahora no hay nada (o no tengo actualizado bien mi VS2012), pero la verdad es que el nuevo modo offline se agradece y mucho.

PD: por cierto si alguno se aburre los invito a ver los contenidos del directorio [$tf] >> back to hell !!!

Saludos @ La Finca

El Bruno