Check out en Team System

Este post esta básado y contiene textos e imagenes directamente tomados del artículo Check Out in Team System de Martin Woodward, publicado bajo licencia Creative Commons. Todos los textos en cursiva han sido 'directamente' traducidos del artículo anteriormente citado las partes que no están en cursiva son de mi cosecha. Una vez aclarado esto, vayamos al grano…

Cada vez más gente me está preguntando ¿por qué TFS cuando hace check out, no obtiene la última versión?.

El problema es que la terminología empleada varia dependiendo de cual sea el gestor de fuentes del que vienes. En Visual Source Safe o PVCS, Check Out significa "dame la ultima versión del archivo y bloqueale para que ningún otro pueda editarlo". En CVS y Subversion, Check Out significa "dame la última versión". Si estas usando las caracteristicas de control de código fuente de Team System, entonces, Check Out significa "dile al servidor que yo quiero editar este archivo y marca el archivo como escribible en mi sistema de archivos", al mismo tiempo que tu haces Check Out del archivo tambien tiene la opción de bloquerlo usando uno de tres tipos de bloque existente (none, Check Out o Check In).

Team System tiene el concepto de Workspaces. El servidor conoces tu Workspace, conoce que directorios locales has mapeado en que Workspace, que versiones de los archivos tienes en este Workspace y de que cambios pendientes has informado al servidor. Para obtener la última versión de un archivo, debes llamar explicitamente al comando Get Latest para descargar los archivos.  Si alguien crea una nueva versión de un archivo, no lo verás en tu sistema local de archivos hasta que vuelvas ha ejecutar Get Latest otra vez. Y no esto no se puede cambiar, ni siquiera usando Check Outs exclusivos.

Cuando hace Check Out de un archivo, lo que realmente estás diciendo es "Servidor, estoy a punto de editar la versión 3 del archivo"

Finalmente, cuando haces Check In del archivo, coges el archivo desde tu Workspace local y le pasas hasta el servidor. Este archivo ahora se convierte en la última versión.

Ahora, imagina que no has optenido la última versión antes de hacer el Check Out. Cuando haces el Check In, el servidor sabe que los cambios fueron hechos en la versión 1 del archivo, por eso te avisa de que es un cambio conflictivo y te pide que resuelvas estos conflictos antes de hacer Check In en este archivo.

Why does it not just get the latest version when you do a check-out the file? The problem with that is that if it were to get the latest version then that might introduce new dependencies on files that you have not got yet. Team System plays safe and only gets the file when you tell it to.

¿Por qué no simplemente obtener la última versión cuando tu hace Check Out de un archivo? El problema con este enfoque es que si obtuviesemos la última versión podríamos intruducir nuevas dependencias repecto a archivos que aun no tenemos. Team System opta por el enfoque más seguro y optiene el archivo solo cuando se lo pedimos.

Hasta aqúi las partes relevantes de como funciona el tema. Pero yo voy a ir un paso más allá que el amigo Martin Woodward, explicando que significa eso de "introducir nuevas dependendias". El problema es que cuando hacer Check Out implica obtener la última versión, nosotros perdemos el control de que es lo que realmente obtenemos. Se puede dar el caso de que simplemente para hacer una edición menor en un archivo, por ejemplo para hacer un Workarraound temporal para poder continuar con una pequeña tarea, no tengamos que bajar infinidad de ficheros solo para poder compilar. Si el archivo del que hacemos obtenemos la última versión cambio mucho, y por ejemplo, llama a nuevas partes del código que a nosotros no nos interesan, el obligar la obtencion de la última versión no obliga a bajar un motón de código que no es relevante para nuestra tarea actual.

La manera de trabajar en Team System tambien soporta algunas técnicas avanzadas de gestión de código que son dificiles de llevar a cabo con otros gestores de fuentes, como por ejemplo Golden Lines o Quality Gates, en las que puede que tu no tengas permiso para integrar código, que las integraciones de nuevo código solo se hagan en un determinado momento fijado en el tiempo o que el desarrolador ni siquiera sea quien puede integrar ese código, sino que hay un equipo exclusivamente encargado de la integración. Resumiendo hay patrones de gestión de código fuente que son dificiles o imposibles de llevar a cabo si se realiza la obtención de la última versión en el momento de realizar el Check Out.

En VSS y otros gestores que implementan el enfoque de obtener última versión al hacer Check Out, esto se solucionaba, quitando 'a manopla' el atributo de solo lectura al proyecto, lo que de todos modos te llevaba a tener que corregir una incosistencia.

Eso si, he de reconocer que este escenario no es habitual, y que no acaba de convencerme al 100% el enfoque que han elegido en Team System, sobre todo por una cuestión: se separa de el enfoque al que estamos acostumbrados. Seria simple haber puesto una opción que permitiese variar el comportamiento. Parece que esta posibilidad la introduciran en proximas revisiones/versiones de Team System, puesto que de hecho el Visual Studio 2005 Team Foundation Server MSSCCI Provider (que se usa para acceder al gestor de fuentes de TFS desde Visual Studio 2003, PowerBuilder, VB 6.0 etc…) ya soporta "GetLatest on Checkout support".

De todos modos existen algunos 'workarrounds' que nos pueden ayudar. Por ejemplo podemos añadir una macro de Visual Studio para que cuando abramos un fichero que es de solo lectura (y por tanto, es probable que este en el gestor de fuentes) se obtenga su última versión. Para ello solo tenemos que hacer Alt + F11 en visual estudio, y añadir en el archivo EnviromentEvents, dentro del modulo EnviromentEvents el siguiente código:

Otra opción es hacer una macro similar que podemos asociar a un menu o a un botón que, nos permita de manera simultanea optener la última versión y hacer Check Out: