You are currently browsing the tag archive for the ‘control de versiones’ tag.

Existen no sé cuántas páginas en Internet que te explican por qué el control de versiones git es mejor que Subversion. No quiero decir que git es peor, pero poco de lo que provee realmente necesitas en muchas ocasiones. Así quiero dar razones por qué quedar con Subversion – sobre todo para los proyectos que ya lo están usando.

Trabajar en Corea del Norte

El cambio más importante de git respecto a Subversion es tener múltiples repositorios en lugar de uno. Mientras en Subversion te puedes confundir, sobre qué rama trabaja tu copia de trabajo, con git te puedes confundir sobre la rama y, además, sobre si has publicados tus cambios locales a qué otro repositorio.

Ninguna página sobre git pierde advertir, que estos repositorios locales te permiten trabajar off-line. Esto habría sido una maravilla con la velocidad del internet en el siglo pasado. Hoy no conozco ninguna empresa informática donde los empleados serían capaces trabajar sin red. ¿Qué te sirve hacer un check-in local si no puedes compilar porque el compilador descarga bibliotecas de un disco en red? Por supuesto, otra cosa es si te envían frecuentemente a Corea del Norte u otro lugar, donde el WIFI de alta velocidad no suele ser la regla.

Copiar repositorios enteros en lugar de ramas

Otra publicidad para git suele ser el cheap branching (ramificación barata), es decir, crear ramas nuevas cuesta poco. Crear ramas es rápido en git porque sólo se crean en tu repositorio local. En Subversion debes crear la rama en el repositorio. No obstante, no ralentiza mucho. La mayor parte de la creación pasas tecleando el nombre de la nueva rama – algo que git no te ahorra tampoco.

Ahora depende como quieres trabajar con tu nueva rama. Una es reciclar tu copia de trabajo y hacerla apuntar a la nueva rama. Esto se hace con switch en Subversion y con checkout en git. Como git no accede a la red, es más rápido. No obstante la pregunta es, si realmente quieres trabajar así, porque puedes confundir la rama en que piensas trabajar con la en que realmente trabajas. Los ficheros modificados en tu copia de trabajo se mantienen y serán ahora ficheros modificaciones sobre la nueva rama a que cambiaste. Si la rama anterior era de una versión de hace un año, con un poco de suerte no sólo harás un check-in de las tres líneas que has modificado sino, además, del estado que tuve el fichero hace un año.

Por no provocar tu suerte decides a editar cada rama en un directorio aparte. Así el flujo de trabajo es así: en Subversion, creas la rama en el repositorio y haces un check-out de lo que necesitas. En git haces una copia (clone) del repositorio entero y creas la rama. Es decir, primero copias el repositorio entero y no sólo lo que necesitas. Pero luego crear la rama, esto, sí, es rápido.

Como no querrás esperar a tanto cheap branching para cada rama que creas, git invita a crear muchos repositorios de que cada uno contiene lo mínimo posible. Puedes crear repositorios pequeños también con Subversion, pero no lo necesitas. Puedes tener un mega-proyecto en un repositorio y no hace falta comprarte un nuevo disco duro para tu copia de trabajo, ya que sólo necesitas descargarte le parte que quieres modificar.

Guardarlo todo

Otra auto-publicidad de git es guardar ficheros enteros en lugar de diferencias. La ventaja: es más rápido al hacer un check-out, ya que git sólo necesita buscar el fichero dentro de un commit y copiarlo. Subversion, en cambio, debe reconstruir el fichero a base del primer check-in más todos los cambios de la historia.

La ventaja de Subversion es que descargas un fichero por la red. En git descargas el repositorio entero con todas las versiones enteras de todos los ficheros – y así lo tendrás también guardado en tu disco duro.

El directorio .git

Git usa una carpeta escondida den nombre “.git” en el directorio raiz para guardar sus datos. En muchas páginas puedes leer que Subversion no es así, porque guarda una carpeta escondida “.svn” en cada carpeta. Esto era cierto. No obstante, esto ha cambiado desde la versión 1.7 de Subversion. Ahora sólo hay una carpeta “.svn” en el directorio raiz – igual como en git.

Seguridad para la generación selfie

Git hace publicidad con la seguridad de los datos. Una revisión no tiene un número, sino un hash, es decir un número hexadecimal lo suficientemente largo, para que, con seguridad, no podrás memorizarlo. Esto es para que no se altere la integridad del commit. El hash se calcula a base de los datos que componen un commit. Cambiar un byte cambia el hash. Al mismo tiempo, git te permite unir varios commits en uno, mover el origin de una rama a otro commit y hacer desaparecer commits por completo. Lo importante es que los commits no aparezcan como si hubieras probado algo, sino que la historia del repositorio muestra que hiciste todos los cambios completos y correctos a la primera. Sólo falta el botón “me gusta”.

En Subversion, en cambio, se queda la historia sin alterar. Lo que está dentro, se queda – a menos si lo quieres hackear. Si haces un merge de una rama, entonces no se copia la historia entera de la rama añadida sino se crear un nuevo commit, donde puedes poner todos los comentarios sensatos que el release manager necesita para decidir si tu cambio entra o no. Los comentarios y check-ins caóticos de tu rama de desarrollo no entran, porque se quedan únicamente en la rama de desarrollo.

Es cierto que tu repositorio de Subversion acumula ramas de desarrollo difuntas que ocupan espacio aunque ya no se necesitan. En git, el repositorio central sólo necesita guardar lo que realmente está terminado y funcionando. Pero esto surge porque estás dispuesto a jugar con dos repositorios a la vez. Lo puedes hacer también en Subversion. Exportas la rama de release, copias los ficheros a la copia de trabajo del repositorio bonito y haces un check-in.

Un repositorio para el back-up

Finalmente queda por hacer una copia de seguridad de tu repositorio, porque no quieres perder tus cambios si se rompe tu disco duro. Normalmente sólo se hace una copia de seguridad del repositorio central. En Subversion, todos los commits entran en la próxima copia de seguridad. En git, te debes pensar si haces un push al repositorio central o creas algún repositorio intermedio (probablemente en red), sobre qué el administrador de sistema hace una copia de seguridad. Así puedes elegir entre olvidar el push al repositorio central o intermedio o olvidar la copia de seguridad de tu repositorios locales.

Se puede argumentar que cualquier directorio de git es un back-up del repositorio central. Esto puede ser válido pero también puede que no. Es posible que sólo empujas commits buenos al repositorio central y el repositorio local contiene muchos más commits “de trabajo”. Es posible que estos no quieres tener en el repositorio central. Además hay configuraciones que son locales a un repositorio determinado – por ejemplo los scripts (hooks) que se llaman en caso de un commit. En fin, es probable que todavía prefieres hacer un back-up del repositorio central como se hace con el repositorio de Subversion, porque la existencias de múltiples clones no te tranquiliza lo suficiente.

El pull request

Una ventaja en el ámbito de git es el pull request. Es un flujo de trabajo en que un desarrollador dice que ha terminado algo y pide al jefe de integrarlo en la rama de release. Antes unas cuantas personas más pueden dar su acuerdo o incluso añadir nuevos commits con cambios. Esta funcionalidad no es de git mismo, sino un software adicional que ofrecen servidores para proyectos en git como GitHub.

Los servidores de Subversion no suelen ofrecer esto aunque teóricamente podrían. Pero es cuestionable si hace falta. En muchos proyectos, los desarrolladores pueden comunicarse de otras formas, se puede convenir que nadie hace un check-in en la rama de release menos el autorizado y siempre es posible crear una rama de la rama para proponer modificaciones adicionales. No aparece todo tan bonito en una página web, pero posible, sí, que es.

Y claro, siempre es posible que alguién implemente algo parecido al pull request para Subversion.

Quédate con lo que tienes

Si ya trabajas en git, entonces déjalo. Git no es peor que Subversion. Pero antes de migrar mil proyectos a git, piénsatelo bien. La mayoría de los argumentos a favor de git se mueven en el nivel de alguien que quiere vender su coche normalito para comprarse un SUV. Como no hay razones de verdad a favor de un SUV, busca razones que, al menos para él, aparentan serlo. El SUV gasta más, cuesta más, ocupa más espacio y es tan estrecho por dentro que la rueda de repuesto no cabe. Pero es mejor porque tiene capabilidad de todo-terreno. Aunque esta nunca aprovecharé porque no quiero que me salpique la tierra a mi bonito coche.

Antes de invertir en git, aprende a diferenciar los usuarios de los creyentes en git. Haz un análisis sobre qué esperas de un control de versiones y piensa si el cambio vale la inversión. Si ni siquiera te convence su propia publicidad, entonces es mejor seguir con lo que tienes.

Los repositorios descentralizados son una ventaja cuando los desarrolladores están distribuidos sobre el planeta como suele ser en muchos proyectos de código abierto. No obstante, en las empresas, los desarrolladores suelen trabajar en la misma oficina. Y existe un buen compromiso: el programa git svn permite trabajar con Subversion como si fuera git y, al mismo tiempo, permite trabajar con Subversion como si fuera Subversion. Es decir, es como un coche normal pero con tracción de cuatro ruedas.

Referencias

  • Página principal de Subversion
  • Página principal de git. git svn es parte del paquete git.
  • Página principal de GitHub

Lectura adicional

Anuncios

Una herramienta de control de versiones tiene un cierto potencial de adicción, ya que es difícil de dejar de usarlo cuando una vez se ha conocido sus ventajas. En este artículo queremos hablar qué ficheros conviene guardar en un control de versiones y cuando conviene no usarlo. “No usar un control de versiones” significa guardar los ficheros en el sistema de ficheros de sistema operativo, es decir en los directorios de toda la vida.

Describo en otro artículo lo que es un control de versiones. En este artículo asumo que el lector ya lo sabe.

En el artículo anteriormente mencionado defino las dos razones de usar un control de versiones, que son:

  1. Ayuda a que varios programadores pueden trabajar en paralelo.
  2. Permite mantener varias versiones de un mismo programa a la vez.

Una conclusión de esto es que no se usa un control de versiones si no se da al menos una de estas condiciones, ya que no vale la pena usar una herramienta adicional si no trae beneficio. No se pueden acceder ficheros bajo el control de versiones excepto con la misma herramienta y está puede tener problemas de compatibilidad con versiones nuevas del sistema operativo como cualquier otro programa. Tampoco es fácil añadir espacio cuando el repositorio ya ha llenado el disco duro entero. Una carpeta simple, por lo contrario, es fácilmente manejable en cualquier plataforma.

La consecuencia de no programar en paralelo es bastante obvia: un sólo programador no corre riesgo de no poder trabajar por culpa de otro. Mientras uno trabaja sólo es mucho más fácil guardar todos los ficheros en las carpetas habituales, aunque eso sí: organizando los ficheros para al menos teóricamente será fácil subirlos a un control de versiones. Nunca sabes si algún día habrá otro programador contigo.

O que habrá múltiples versiones. Mantener múltiples versiones es algo habitual en proyectos grandes. Mientras el cliente prueba una versión, los programadores ya desarrollan la próxima. Si es un software que al menos en principio cualquiera pueda descargar y usar, entonces conviene mantener el código bajo un control de versiones, ya que siempre habrá varias versiones en uso. El caso contrario es un software a medida.

Una vez entregado el software a medida al cliente funcionando, nadie se interesará por un estado intermedio durante el desarrollo. Hay una versión final y punto. Entonces se guarda esta última versión en carpetas del sistema operativo y se puede liberar el espacio en el control de versiones. Si el cliente un día quiere un cambio, se puede volver a subirlo – pero entonces a una herramienta de la última generación y no el control de versiones de hace diez años.

Si el cambio está terminado y aceptado por el cliente, entonces se vuelve a guardar la versión final en un directorio del sistema operativo. Si queremos guardar estas dos versiones, entonces podemos usar dos subcarpetas “versión 1” y “versión 2”. Personalmente prefiero usar la fecha, algo como “Versión 2010-06-01”. Así uno no se lía con los números de versiones y queda aún más claro cual es la más reciente.

En fin, guardar proyectos en carpetas simples en lugar de mantenerlos en un control de versiones puede ser una mejor solución para proyectos pequeños y con pocas versiones.

Finalmente quedan todavía dos puntos adicionales a subrayar:

  • Un control de versiones no reemplaza una copia de seguridad. Guardar su trabajo diario en un disco duro alternativo es importante para no perder datos en caso de averías.
  • Aunque el primer fin de un control de versiones es guardar las versiones de sus propios ficheros fuentes, puede convenir guardar bibliotecas externas con las fuentes, ya que una nueva versión de una biblioteca externa no está garantizada de funcionar con una versión antigua del programa. No es un error guardar todas las bibliotecas externas para cada proyecto por separado, aunque serán siempre las mismas bibliotecas. Simplemente piensa qué frustración puede ser sacar un proyecto viejo del armario y que este no compila directamente porque todavía toca buscar todas las bibliotecas por ahí y a saber con qué versión.

Por cierto, nombrar carpetas con fechas es una manera simple de organizar copias de seguridad del trabajo del día.

Referencias

¿Qué es un control de versiones?

Un control de versiones una herramienta para el desarrollo de software que facilita principalmente dos funciones:

  1. Ayuda a que varios programadores pueden trabajar en paralelo.
  2. Permite mantener varias versiones de un mismo programa a la vez. (De ahí “control de versiones”)

Trabajar en paralelo

Si dos programadores realizan cambios en un mismo fichero fuente, entonces sobreescriben los cambios del otro cada vez cuando lo guardan. Incluso si un equipo de trabajo llega a organizarse para que esto no sucede, todavía es probable que todos los “prints”, “ifs”, y demás modificaciones temporales que un programador pueda poner para probar su código molesten a los demás. Si el programa no compila entonces todos los demás están parados hasta que se haya arreglado el error.

Aquí ayuda un control de versiones. Los ficheros “buenos” – es decir una versión que al menos compila – están en un servidor, el “repositorio”. Un programador trabaja sobre una “vista” a estos ficheros (habitualmente una copia local en el ordenador del programador). Si quiere cambiar un fichero, entonces debe “sacarlo del control” (hacer un check-out o desproteger). Mientras tanto los demás programdores siguen viendo la versión original del fichero y no están afectados por las modificaciones de un miembro de equipo.

Cuando el primer programador cree que su versión modificada funciona razonablemente bien, entonces la “sube” (mete, hace un check-in o la protege). Con esto se ha creado una nueva versión, que será la que verá todo el mundo que “actualice su vista”. Un control de versiones no reemplaza a una copia de seguridad, porque no se guardan los cambios en el servidor hasta que el programador lo ordene. Y esto puede durar un mes en ocasiones.

Merge

Un control de versiones sólo permite “subir” un fichero, si es el sucesor de la versión de que fue sacado. Puede suceder que dos programadores sacan sus versiones personales de la misma versión. El primero puede hacer un check-in de sus cambios sin problemas, pero el segundo debe conciliar sus cambios con las modificaciones del otro programador. Un fichero sacado no se actualiza con las versiones que los otros programadores hayan metido, ya que sobreescribirían las modificaciones propias.

La solución es un “merge” (inglés para combinar). Habitualmente se abre una pantalla con las tres versiones afectados: La versión original de donde se partió, la versión a meter y la última versión bajo control. En un caso simple se ha modificado el fichero en puntos diferentes y se pueden simplemente incluir los cambios de la versión más reciente en la versión a meter. Dos cambios en una misma línea de código causan un “conflicto” que el programador debe resolver a su criterio y con la ayuda del otro programador. Muchas veces un control de versiones puede combinar versiones sin conflictos de forma automática. No es posible hacer un merge en ficheros binarios.

Mantener varias versiones

En muchos programas de uso común es habitual mantener varias versiones. Por ejemplo, no todo el mundo está dispuesto a instalar un nuevo sistema operativo cuando Microsoft publique una nueva versión de Windows. Así Microsoft debe mantener varias versiones de Microsoft Windows al mismo tiempo que está desarrollando la próxima generación.

¿Qué significa varias versiones? Cada vez cuando un programador sube sus cambios, se crea una nueva versión que el sistema enumera con un número secuencial. Podemos decidir que alguna de estas versiones, digamos la versión 3124, será destinada a ser una “release” oficial. Entonces se “etiqueta”, por ejemplo como “Windows 8 alpha” y se crea una nueva “rama” (branch en inglés). La rama principal (“trunk” en inglés) es la en que los programadores hagan el desarrollo nuevo. La rama “Windows 8 alpha” existe en paralelo y sirve para corregir los errores que todavía pueda tener. En esta versión interesa más llegar a una versión “estable”, un “release”, que añadir un nuevo desarrollo.

Lógicamente, todos los errores que se encuentran en la versión “Windows 8 alpha” habrá que corregir también en la rama de desarrollo principal. También puede suceder que alguna funcionalidad nueva de la rama de desarrollo entra en la rama de la versión “release”. En general, los programadores tienen que modificar varias versiones y el control de versiones les permite determinar cuales.

Como es imaginable, una rama de una release puede bifurcarse también. Una sigue con las correcciones de la versión (oficial) 8.0, la otra está destinada a incluir mejoras para la release 8.1. En el momento que una versión ya no incluirá nuevas funcionalidades se “congela”. Cuando ya no se trabaja sobre ella ya no está “soportada”.

Pequeña lista comentada de control de versiones

Hasta algunos años, la comunidad de código abierto ha usado con mucho gusto el CVS (Concurrent Versions System). Ahora se usa más el Subversion, que ofrece un cliente integrado en el explorador de Windows que se llama TurtoiseSVN. Es todo gratis y una buena solución para la mayoría de los proyectos.

Cuando gratis no es un requisito puede convenir usar IBM® Rational® ClearCase®, un programa completo que permite un uso por línea de comando y por interfaz gráfico. Microsoft Visual SourceSafe es un extra con las versiones de empresa de Visual Studio, pero que a veces da impresión de ser ni visual ni seguro. La ventaja que tiene es que se integra bien con el Visual Studio.

Quien piensa en grade debe tener en cuenta que eligir una herramienta de control de versiones es una decisión estratégica de la empresa. Una base de datos es lo más difícil de actualizar en un programa y un control de versiones no es otra cosa que una base de datos donde los datos son ficheros. Es bastante probable que una empresa todavía usa el control de versiones de hoy en diez años.

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevos mensajes por correo.

Únete a otros 50 seguidores

Archivos

octubre 2017
L M X J V S D
« Ene    
 1
2345678
9101112131415
16171819202122
23242526272829
3031