Cómo hacer animación javascript correctamente. Bibliotecas y complementos de JavaScript prometedores para animación. Complementos de JavaScript para animación

Misha Radionov

¿Qué son los sistemas de control de versiones y por qué los necesitas?

Volver a

Imagine la situación: contrató a un desarrollador para agregar, digamos, una función de pedido rápido a su tienda en línea. Dado que el sitio debe funcionar y generar ingresos todo el tiempo, el desarrollador decide trabajar en su servidor local.

Mientras estaba funcionando, el diseñador envió un nuevo logotipo, que usted reemplazó inmediatamente en la plantilla de la versión principal del sitio. Al mismo tiempo, redujiste la fuente en los nombres de los productos para que todo quepa en la pantalla del netbook de uno de tus clientes. Luego actualizaste un par de imágenes de productos. En este momento, el desarrollador decidió hacerle un favor: eliminar la funcionalidad francamente innecesaria en su versión de su sitio que escribió el desarrollador anterior. Como suele suceder, ambos piensan que no hicieron nada serio. Pero estás equivocado.

Cuando la versión del desarrollador se carga en el sitio, todos los participantes en el desarrollo se agarran la cabeza. Los resultados de su trabajo se borran, aparecen errores. No está claro cuál es el problema. Con suerte, en este punto al menos tendrá a mano una copia de seguridad funcional y, en el peor de los casos, pasará varios días detectando problemas manualmente. ¿Cómo evitar caer en una situación así? Hablemos.

¿Qué es VCS?

Sistema de control de versiones (del sistema de control de versiones en inglés, VCS o sistema de control de revisiones): software para facilitar el trabajo con información cambiante de Wikipedia.

Y ahora de forma sencilla

Un sistema de control de versiones le permite almacenar múltiples versiones del mismo documento, volver a versiones anteriores si es necesario, determinar quién realizó un cambio particular y cuándo, y mucho más.

En otras palabras, VCS permite que varios desarrolladores modifiquen los mismos archivos simultáneamente y sin crear copias locales en sus computadoras. En este caso, todas las opciones de modificación se guardan por separado y puede realizar diferentes opciones el mismo archivo, teniendo en cuenta diferentes ediciones de diferentes personas. Si varios cambios afectan a un mismo fragmento del documento, el sistema le pedirá que seleccione la opción deseada.

Normalmente se utiliza para trabajar con un sistema de control de versiones. computadora separada(servidor) o un servicio de Internet que brinde la oportunidad de alquilar dicho servidor.

Ejemplo sencillo

Si varias personas trabajan en un documento de Excel, sólo una persona puede editar el archivo; el resto tiene acceso de sólo lectura. Con VCS tienes la oportunidad de editar un archivo a la vez y por todos. La única condición es que después de realizar cambios, el archivo debe guardarse en el servidor y no en computadora local. Pero como se mencionó anteriormente, las herramientas le permiten realizar tales acciones de manera fácil y sencilla.

Sistema de control de versiones en Flag Studio

En nuestro trabajo utilizamos el sistema de control de versiones Git. Este sistema es uno de los VCS más comunes. Esto resulta en un gran apoyo por parte de la comunidad Git. Otra ventaja es la facilidad para dominar el sistema, porque... hay un amplio espectro productos de software desarrollado específicamente para este sistema.

Usamos un programa de desarrollo de código llamado IntelliJ IDEA. Proporciona un IDE, es decir, una gran base funcional para los desarrolladores, incluida una interfaz conveniente para trabajar con el control de versiones. Entonces, sin salir del programa, podemos ver qué cambios realizó uno u otro desarrollador en el sitio que necesitamos. O, sin temor a perder sus cambios, obtenga los cambios realizados por otro desarrollador. La interfaz IDEA se parece a esto:

Para almacenar versiones utilizamos servicio en la nube Bitbucket. Este servicio tiene una interfaz conveniente y, además de los servicios para almacenar sus versiones, le permite administrar las reglas de acceso a sus productos para diferentes usuarios. Ventaja de usar almacenamiento en la nube es la ausencia de requisitos de conocimiento de la configuración y administración del servidor. Obtienes todo listo para usar y puedes comenzar a usarlo de inmediato. Todo lo que subes a bitbucket es privado, es decir. Sin tu permiso, nadie más podrá ver lo que almacenas. Interfaz de Bitbucket:

¿Qué nos aporta el uso de VCS?

• Plena confianza de que los archivos que recibimos del sistema están siempre actualizados en cada momento.
• La capacidad de obtener la versión requerida desde cualquier computadora que le permita conectarse al servidor.
• Al guardar un archivo en VCS, no necesita pensar en el hecho de que alguien que trabaje con el mismo archivo volverá a guardar y sobrescribirá los cambios.
• Para los desarrolladores de software, el uso del sistema también les permite aceptar/rechazar los cambios realizados por uno de los desarrolladores.

¿Qué aporta esto a nuestros clientes?

Volvamos a la situación comentada al principio. Como sería con VCS. El desarrollador carga su código en una rama separada. Revisas los cambios y sólo los aplicas si ves que todo está bien. Todo se almacena en un solo lugar, seguro, rápido y conveniente. Y cuando hay varios desarrolladores, no podrás prescindir de VCS en absoluto.

Por favor habilite JavaScript para ver el

Sistema de control de versiones distribuido Git. Parte 1

Introducción

Serie de contenido:

1. Introducción

Mientras trabajan en un proyecto, sus participantes a menudo encuentran problemas con la sincronización y el mantenimiento del historial de archivos, que los sistemas de control de versiones (VCS) ayudan a resolver. El propósito de esta serie de artículos es presentar al lector los principios de funcionamiento del VMS y considerar en detalle uno de ellos, Git. ¿Por qué Git? Este sistema ha ido ganando popularidad últimamente y es difícil sobreestimar su importancia para el software libre (y para el proyecto GNU/Linux en particular).

Estamos consistentemente en esquema general, analizaremos las características de los sistemas de control, hablaremos de su arquitectura y las principales características de la aplicación en cuestión. Además, revisaremos las interfaces existentes actualmente para trabajar con Git.

El autor omite deliberadamente la terminología de funciones, teclas y otras sutilezas para presentarle una imagen clara, clara y general. Este artículo asume que el lector está familiarizado con los sistemas operativos (SO) similares a Unix y también tiene conocimientos basicos en el campo de la algorítmica y la informática en general.

En los siguientes materiales profundizaremos en la estructura y filosofía de Git, las particularidades de este sistema y las sutilezas. trabajo practico consigo. El ciclo se completará con un artículo sobre la interacción de Git con otros VCS (como Subversion, CVS, Mercurial, etc.).

2. Git es...

Git es un sistema de control de versiones de archivos distribuido. El código del programa está escrito principalmente en C. El proyecto fue creado por Linus Torvalds en 2005 para gestionar el desarrollo. núcleos de Linux y, al igual que GNU/Linux, es software libre, con el uso de terceros sujeto a licencias GNU GPL versión 2. En definitiva, este acuerdo se puede caracterizar como software de código libre que debe desarrollarse de forma abierta, es decir. cualquier programador tiene derecho a seguir mejorando el proyecto en cualquier etapa. Por mi propio bien por mucho tiempo existencia este sistema Ha sido introducido por muchos desarrolladores líderes. Git se utiliza en proyectos conocidos por la comunidad Linux como Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. Sistemas de control de versiones

Los sistemas de control de versiones son software diseñado para automatizar el trabajo con el historial de un archivo (o grupo de archivos), monitorear cambios, sincronizar datos y organizar el almacenamiento seguro de proyectos. En resumen, el objetivo principal de los sistemas de control de versiones es facilitar el trabajo con información cambiante. vamos a solucionarlo vista general desarrollo con el ejemplo.

Supongamos que hay un proyecto que estás desarrollando, varios departamentos de programadores y tú eres el coordinador (o responsable). En relación al sistema de control, ya sea un servidor (si estamos hablando de sobre un sistema centralizado) o una máquina local, cualquier desarrollador de proyecto está limitado únicamente por los derechos de acceso para cambiar y/o leer versiones de archivos de este repositorio. En cualquier momento puedes revertir los datos a la versión que necesites. Usted, como coordinador, puede restringir el acceso a ciertos usuarios para actualizar la versión del archivo. SUV también proporciona una interfaz para monitorear y buscar versiones de archivos. Por ejemplo, puede crear una consulta: "¿Dónde y cuándo se cambió este fragmento de código?"

El sistema asume un almacenamiento de datos seguro, es decir. cualquier bloque almacenado en él tiene muchos clones. Así, por ejemplo, si un archivo está dañado, puedes reemplazarlo rápidamente con una copia. Para reducir el volumen de datos del proyecto, a menudo se utiliza la compresión delta, un tipo de almacenamiento en el que no se almacenan las versiones de los archivos en sí, sino sólo los cambios entre revisiones sucesivas.

4. Diferencias entre sistemas de control de versiones distribuidos

Los sistemas de control de versiones distribuidos son VCS, cuyo principal paradigma es la localización de datos para cada desarrollador de proyectos. En otras palabras, si en los SUV centralizados todas las acciones, de una forma u otra, dependen del objeto central (servidor), entonces en los SUV distribuidos cada desarrollador almacena su propia rama de versiones de todo el proyecto. La conveniencia de un sistema de este tipo es que cada desarrollador tiene la oportunidad de trabajar de forma independiente, intercambiando de vez en cuando versiones intermedias de archivos con otros participantes del proyecto. Veamos esta característica, continuando con el ejemplo anterior.

Cada desarrollador tiene su propio repositorio local en su máquina, un lugar para almacenar versiones de archivos. El trabajo con los datos del proyecto se realiza en su repositorio local, y para ello no es necesario mantener contacto con otras (incluso las principales) ramas de desarrollo. La comunicación con otros repositorios solo será necesaria al cambiar/leer versiones de archivos de otras ramas. En este caso, cada participante del proyecto establece los derechos de lectura y escritura de su propio almacenamiento. Así, todas las sucursales en los SUV distribuidos son iguales entre sí, y la principal la asigna el coordinador. La única diferencia entre la rama principal es que los desarrolladores la admirarán mentalmente.

5. Funciones y funciones principales de Git

Vale la pena decir que el sistema, si no causó sensación, sí conmovió un poco a la comunidad SUV con su novedad y ofreció nueva manera desarrollo. Git proporciona herramientas flexibles y fáciles de usar para mantener el historial del proyecto.

Una característica especial de Git es que es posible que el trabajo en las versiones del proyecto no se realice en orden cronológico. El desarrollo se puede realizar en varias ramas paralelas, que pueden fusionarse y dividirse en cualquier momento durante el proceso de diseño.

Git es un sistema bastante flexible y su ámbito de aplicación se limita no solo al desarrollo. Por ejemplo, periodistas, autores de literatura técnica, administradores y profesores universitarios bien pueden utilizarlo en su línea de trabajo. Estas tareas incluyen el control de versiones de cualquier documentación, informe o tarea.

Resaltemos las principales diferencias entre Git y otros sistemas de gestión distribuidos y centralizados.

arquitectura git

SHA1 (Algoritmo Hash Seguro 1) es un algoritmo hash criptográfico. Cada archivo de proyecto Git consta de un nombre y contenido. El nombre son los primeros 20 bytes de datos y está claramente escrito en cuarenta caracteres en el sistema numérico hexadecimal. Esta clave se obtiene aplicando hash al contenido del archivo. Entonces, por ejemplo, al comparar dos nombres, podemos decir con casi un cien por ciento de probabilidad que tienen mismo contenido. Además, los nombres de objetos idénticos en diferentes ramas (repositorios) son los mismos, lo que le permite operar directamente con los datos. Una buena adición a lo anterior es que el hash le permite determinar con precisión si los archivos están dañados. Por ejemplo, al comparar el hash del contenido con el nombre, podemos decir con bastante precisión si los datos están dañados o no. En lo que sigue, por nombre nos referiremos al nombre del archivo, y la cadena de caracteres se denominará hash SHA1.

Cabe mencionar las llamadas colisiones. "Determinar el daño con bastante precisión" significa que hay archivos, de diferente contenido, cuyo hash SHA1 es el mismo. La probabilidad de que se produzcan tales colisiones es muy pequeña y evaluación preliminar es igual a 2 elevado a -80 (~10 elevado a -25). Evaluación precisa no, porque en este momento La comunidad internacional no ha podido descifrar eficazmente este esquema criptográfico.

Objetos Git

Trabajar con versiones de archivos en Git se puede comparar con las operaciones normales en el sistema de archivos. La estructura consta de cuatro tipos de objetos: Blob, Árbol, Confirmación y Referencias; algunos de ellos, a su vez, se dividen en subobjetos.

Blob (objeto binario grande) es un tipo de datos que contiene solo el contenido del archivo y su propio hash SHA1. Blob es el principal y único medio de almacenamiento de datos en la estructura de Git. Se puede establecer un paralelo entre este objeto y los inodos en los sistemas de archivos, ya que su estructura y propósito son en gran medida similares.

Árbol

• propio hash SHA1;
• hash SHA1 de blobs y/o árboles;
• derechos de acceso a sistemas Unix;
• Nombre simbólico del objeto (nombre para uso interno en el sistema).

En esencia, un objeto es análogo a un directorio. Define la jerarquía de los archivos del proyecto.

Comprometerse– un tipo de datos que contiene:

• propio hash SHA1;
• un enlace a exactamente un árbol;
• enlace al compromiso anterior (puede haber varios);
• nombre del autor y hora de creación del compromiso;
• el nombre del confirmador (el confirmador es la persona que aplicó el compromiso al repositorio, puede diferir del autor) y la hora en que se aplicó el compromiso;
• pieza de datos arbitraria (un bloque se puede utilizar para firma electrónica o, por ejemplo, para explicar los cambios de confirmación).

Este objeto está diseñado para almacenar una instantánea (versión) de un grupo de archivos en un momento determinado; puede compararla con un punto de control. Las confirmaciones se pueden fusionar, ramificar o, por ejemplo, establecer en una estructura lineal, reflejando así la jerarquía de las versiones del proyecto.

Referencia es un tipo de datos que contiene una referencia a cualquiera de los cuatro objetos (Blob, Árbol, Confirmación y Referencias). Su finalidad principal es hacer referencia directa o indirecta a un objeto y ser sinónimo del archivo al que hace referencia. Esto aumenta la comprensión de la estructura del proyecto. Es muy inconveniente operar con un conjunto de caracteres sin sentido en el nombre; a diferencia del hash SHA1, se puede nombrar de la manera que sea más conveniente para el desarrollador.

De los enlaces, a su vez, podemos distinguir una serie de subobjetos que tienen algunas diferencias: Rama, Etiqueta. Mirémoslos.

Rama (Cabeza, Rama)– un enlace simbólico, que apunta a la última confirmación en la cronología de una determinada rama y almacena el hash SHA1 del objeto. Es un tipo de datos de sistemas de archivos registrados por diario. este tipo El objeto no está definido en Git, sino que se hereda de los sistemas operativos y de archivos. Una rama se utiliza como sinónimo del archivo al que hace referencia, es decir. Git te permite operarlo directamente. Puede darse el lujo de no pensar si está trabajando con la última versión o no.

Etiqueta– un tipo de datos que, a diferencia de las ramas, invariablemente se refiere al mismo objeto de tipo blob, árbol, confirmación o etiqueta. Este, a su vez, se puede dividir en ligero (etiqueta ligera) y pesado o anotado (etiqueta anotada). Una etiqueta ligera, excepto por la inmutabilidad del enlace, no se diferencia de las ramas ordinarias, es decir. contiene solo el hash SHA1 del objeto al que se hace referencia dentro de sí mismo. Una etiqueta anotada consta de dos partes:

• la primera parte contiene su propio hash SHA1;
• la segunda parte consta de:
  • SHA1 del objeto al que apunta la etiqueta anotada;
  • el tipo de objeto al que se hace referencia (blob, árbol, confirmación o etiqueta);
  • nombre de etiqueta simbólico;
  • fecha y hora de creación de la etiqueta;
  • nombre y correo electrónico del creador de la etiqueta;
  • un dato arbitrario (este bloque se puede utilizar para una firma electrónica o para explicar una etiqueta).

En otras palabras, un proyecto en Git es una colección de blobs conectados por una red de árboles. La estructura jerárquica resultante puede, dependiendo del tiempo, reflejarse en forma de confirmaciones: versiones, y para comprender su estructura, Git contiene objetos como enlaces. Excluyendo las acciones con enlaces, casi todo el trabajo con objetos del sistema está lo más automatizado posible desde dentro. Partiendo del mecanismo de enlace, llegamos a la siguiente idea: trabajar específicamente en grupos de archivos. Según el autor, el pensamiento es clave en la filosofía Git. Habiendo especificado, por ejemplo, una operación para una confirmación determinada, elaborará recursivamente su parte a lo largo del árbol al que se refiere. Una extensión de la vista generalmente aceptada de "acción en cada archivo", la innovación simplifica la implementación y el enfoque por parte del programador para las tareas cotidianas de VCS, como fusionar/dividir ramas, automatizando nuevamente el proceso de forma recursiva. Este enfoque Fácil de entender, rápido y flexible para lograr tus objetivos. Muchas de estas características se logran debido a la naturaleza del sistema orientada a Unix, es decir. operante dispositivos estándar Git se basa en soluciones ya presentes en el sistema operativo.

Aclaremos el momento del almacenamiento de datos. El contenido de archivos de diferentes versiones cronológicas ocupa bastante memoria. Así, por ejemplo, en un proyecto de veinte archivos de veinte versiones, el archivo pesará 20 veces más (quizás unos cien megabytes), pero ¿qué pasará si el número de ambos es 10 veces mayor (parece poco)? El tamaño del espacio ocupado aumentará 100 veces (es decir, aproximadamente 1 GB). En problemas reales, la tasa de crecimiento de la memoria ocupada está lejos de depender linealmente del tiempo. Hay varias optimizaciones para resolver este problema:

• cada objeto Git se almacena como un archivo normal (tar.gz);
• La compresión delta secuencial se aplica a toda la jerarquía de archivos.

Veámoslo con un ejemplo.

Tienes un historial de tres años de tu proyecto, con alrededor de mil archivos y cien versiones. Si en algún momento es necesario hacer referencia a la versión más antigua, Git tendrá que comprimir delta todo el historial del archivo. Lamentablemente, este proceso puede tardar hasta el mediodía. Git ofrece hacer lo llamado puntos de control, es decir. almacenar un archivo no archivado a través de una cierta cantidad de versiones, lo que llamamos profundidad de compresión. Luego, en nuestro ejemplo, todo el historial se reduce a un cierto número predeterminado de compresiones delta, al descomprimirlas se puede ver cualquier versión en cronología. Tenga en cuenta que es más recomendable utilizar la compresión delta en ciertos tipos de objetos que están más cerca en la jerarquía; para ello, el repositorio debe ordenarse en consecuencia por tipo y tamaño. Esta serie de operaciones descritas en este párrafo se realiza mediante la función git-repack (y git-gc, que la contiene).

Fusionar y dividir ramas

Esta pregunta requiere mucha mano de obra y es intensa, por lo que introduciremos los conceptos de fusión y separación sólo en términos generales. Veamos el ejemplo nuevamente.

Imaginemos el momento del desarrollo de un proyecto en el que el objetivo principal es la velocidad del programa. Una posible solución táctica es dividir a los desarrolladores en dos grupos, cada uno de los cuales resolverá el mismo problema. En este caso, la rama de la historia del proyecto debería bifurcarse. Este procedimiento se llama ramificación. La acción de ramificar una rama es simplemente crear una copia de la misma, que posteriormente tendrá su propia historia.

Supongamos que recibimos dos resultados ya completados de la misma tarea, en la que trabajaron dos grupos de programadores. ¿Qué debemos hacer? ¿Ves qué código es más rápido y confiable? Es demasiado simple, pero no siempre es la mejor solución. Una buena solución es comprender un poco el código y los archivos y dividirlos en subtareas o bloques de código. Y sólo entonces podremos identificar las fortalezas y debilidades de estas piezas. Por supuesto, esta opción sólo es adecuada si has previsto de antemano que más adelante podrás juntar todas estas partículas. El caso en el que usted mismo desarrolla el código, mejorando y corrigiendo algunos errores, es equivalente al ejemplo dado. este proceso combinar dos números enteros en uno se llama fusión. El proceso de combinar dos versiones es el momento clave de la gestión de proyectos. Sea como fuere, debes evitar la ejecución automatizada de esta operación. rasgo distintivo Git es el más confiable y justo. manera rápida resolviendo el problema de la ramificación.

Las ventajas del sistema incluyen:

1. Orientado a Unix.
2. Coherencia ideológica (siguiendo las reglas de uso del sistema, es muy difícil caer en una situación desesperada o conseguir algo que no esperaba).
3. Alto rendimiento (esta es una de las ventajas más obvias del sistema, cuyo precio es la “consistencia ideológica” y la “orientación Unix”).
4. Integración de Git con sistemas de terceros como Subversion, Mercurial,...
5. Administrar un grupo de archivos (el sistema no necesita considerar los cambios en cada archivo por separado, recuerda cualquier cambio en todo el proyecto y, si de repente necesita realizar un seguimiento de cambios individuales, mostrará exactamente la parte asociada con este archivo ).
6. Operación de fusión (implementación máxima automatizada de una tarea compleja).

Las desventajas incluyen:

1. Orientado a Unix (cabe destacar la falta de una implementación madura de Git en sistemas que no sean Unix).
2. La necesidad de ejecutar periódicamente el comando git-gc (empaqueta grupos de archivos y elimina aquellos que no están vinculados por enlaces).
3. Colisiones de hash (coincidencia de hashes SHA1 de archivos con diferentes contenidos).

6. Interfaces Git

"Cuánta gente, tantas opiniones". Intentemos resaltar varios tipos de interfaces para trabajar con el sistema. Para ciertos propósitos, cada uno de los siguientes tipos de aplicaciones es mejor a su manera.

Para las personas que no están estrechamente involucradas en el desarrollo, para los "conservadores", aquellos que aman los "botones y marcas de verificación" y quieren protegerse conscientemente de los esfuerzos exorbitantes de recordar funciones, teclas y muchas sutilezas, una opción al estilo de TortoiseGit o Las extensiones Git son más adecuadas: interfaces simples. Le permiten operar principalmente con el mouse y trabajar en el sistema operativo Windows que muchos conocen.

Exactamente el tipo opuesto de interfaz. Para los programadores que necesitan interactuar constantemente con los empleados y resolver problemas típicos de control de código, para las personas que están acostumbradas a trabajar en sistemas tipo Unix usando una terminal, la vista de consola de aplicaciones es la más adecuada. Son igual de fáciles de usar, un poco más rápidos y más funcionales, pero llevará algún tiempo descubrir cómo usarlos.

Se puede distinguir un tercer tipo de interfaz: una mezcla de los dos primeros. Aquellos. tienes una aplicación de consola, como un shell git nativo. Puedes usar una serie. utilidades adicionales, como Gitk o QGit, para mostrar árboles, simplificar la descripción general de la jerarquía de versiones, las diferencias entre versiones y encontrar los objetos necesarios.

Conceptos básicos de VCS

Introducción

Antes de hablar sobre cualquier sistema de control de versiones específico, es necesario comprender qué es, qué son y por qué aparecieron en primer lugar. Esta conferencia tiene como objetivo proporcionar una introducción inicial al control de versiones y los sistemas de control de versiones, y primero hablaré sobre los orígenes de las herramientas de control de versiones, qué sistemas de control de versiones son populares actualmente y cuáles son las principales diferencias entre ellos.

Acerca del control de versiones

¿Qué es el control de versiones y por qué lo necesita?

Probablemente valga la pena comenzar con la definición de un sistema de control de versiones (VCS): es un sistema que registra los cambios en uno o más archivos para que en el futuro sea posible volver a ciertas versiones antiguas de estos archivos.

Recientemente, los archivos son el resultado final de muchas profesiones (por ejemplo, escribir, trabajos científicos y, por supuesto, desarrollo de software). Se dedica mucho tiempo y esfuerzo a desarrollar y mantener estos archivos, y nadie quiere tener que dedicar aún más tiempo y esfuerzo a recuperar datos perdidos como resultado de cualquier cambio.

Imaginemos que un programador está desarrollando un proyecto que consta de un pequeño archivo (por cierto, el ejemplo es bastante real, no sintético, se encuentra en vida real). Después de lanzar la primera versión del proyecto, se enfrenta a una decisión difícil: es necesario solucionar los problemas informados por los usuarios de la primera versión y, al mismo tiempo, desarrollar algo nuevo para la segunda. Incluso si solo necesita solucionar los problemas que surgen, existe una alta probabilidad de que después de algún cambio el proyecto deje de funcionar y necesita determinar qué se cambió para que sea más fácil localizar el problema. También es recomendable llevar algún tipo de diario. cambios realizados y correcciones para no hacer el mismo trabajo varias veces.

En el caso más sencillo, el problema anterior se puede solucionar almacenando varias copias de los archivos, por ejemplo, una para corregir errores en la primera versión del proyecto y una segunda para nuevos cambios. Dado que los cambios generalmente no son muy grandes en comparación con el tamaño del archivo, es posible almacenar solo las líneas modificadas usando la utilidad diff y luego fusionarlas usando la utilidad parche. Pero ¿qué pasa si el proyecto consta de varios miles de archivos y cien personas trabajan en él? Si en este caso utiliza el método de almacenar copias separadas de archivos (o incluso solo cambios), el proyecto se detendrá muy rápidamente. En conferencias posteriores, usaré el código fuente del programa como ejemplo, pero de hecho, casi cualquier tipo de archivo se puede colocar bajo control de versiones.

Si es diseñador gráfico o web y desea almacenar todas las versiones de una imagen o diseño (y probablemente lo haría), entonces utilizar un sistema de control de versiones es una decisión muy acertada. VCS permite devolver archivos individuales a como antes, volver a estado anterior todo el proyecto, ver los cambios que ocurren a lo largo del tiempo, determinar quién fue el último en realizar cambios en un módulo que de repente dejó de funcionar, quién y cuándo introdujo algún tipo de error en el código, y mucho más. En general, si mientras usa VCS arruina todo o pierde archivos, todo se puede restaurar fácilmente. Además, los gastos generales por todo lo que obtenga serán muy pequeños.

Sistemas de control de versiones locales.

Como se mencionó anteriormente, un ejemplo de un VCS local es extremadamente simple: muchas personas prefieren controlar las versiones simplemente copiando archivos a otro directorio (generalmente agregando la fecha actual al nombre del directorio). Este enfoque es muy común porque es simple, pero también falla con mayor frecuencia. Es muy fácil olvidar que está en el directorio equivocado y cambiar accidentalmente el archivo equivocado, o copiar archivos en el lugar equivocado y sobrescribir los archivos que necesita. Para resolver este problema, los programadores han desarrollado durante mucho tiempo VCS local con una base de datos simple que almacena todos los cambios en los archivos necesarios.

Uno de los VCS más populares de este tipo es RCS (Sistema de control de revisiones), que todavía está instalado en muchas computadoras. Incluso en un quirófano moderno sistema mac La utilidad OS X rcs se instala junto con las herramientas de desarrollo. RCS fue desarrollado a principios de la década de 1980 por Walter F. Tichy. El sistema le permite almacenar versiones de un solo archivo, por lo que debe administrar varios archivos manualmente. Para cada archivo bajo control del sistema, la información de la versión se almacena en un archivo especial llamado archivo original al que se le añaden los caracteres ",v" al final. Por ejemplo, para el archivo file.txt, las versiones se almacenarán en el archivo file.txt,v. Esta utilidad se basa en trabajar con conjuntos de parches entre pares de versiones (un parche es un archivo que describe la diferencia entre los archivos). Esto le permite recrear cualquier archivo en cualquier momento, aplicando parches de forma secuencial. El sistema utiliza la utilidad diff para almacenar versiones. Aunque RCS cumple requisitos mínimos El sistema de control de versiones tiene las siguientes desventajas principales, que también sirvieron de incentivo para crear el siguiente sistema en consideración:

• Trabaje con un solo archivo, cada archivo debe controlarse por separado;
• Mecanismo inconveniente trabajo simultáneo varios usuarios con el sistema, simplemente se bloquea el almacenamiento hasta que el usuario que lo bloqueó lo desbloquee;
• Nadie te libera de las copias de seguridad; corres el riesgo de perderlo todo.

Sistemas de control de versiones centralizados

El siguiente gran desafío fue la necesidad de colaborar con desarrolladores en otras computadoras. Para solucionar esto, se crearon sistemas de control de versiones centralizados (CVCS). Estos sistemas, como CVS, Subversion y Perforce, tienen servidor central, que almacena todos los archivos bajo control de versiones y una serie de clientes que reciben copias de sus archivos. Este ha sido el estándar para los sistemas de control de versiones durante muchos años.

Este enfoque tiene muchas ventajas, especialmente sobre el LES local. Por ejemplo, todo el mundo sabe quién hace qué en el proyecto. Los administradores tienen un control claro sobre quién puede hacer qué y, por supuesto, CSKB es mucho más fácil de administrar que las bases de datos locales en cada cliente. Sin embargo, este enfoque tiene varios inconvenientes graves. La más obvia es que el servidor centralizado es el punto débil de todo el sistema. Si el servidor deja de funcionar durante una hora, los desarrolladores no podrán interactuar durante una hora y nadie podrá guardar una nueva versión de su trabajo. Si el disco con la base de datos central está dañado y no hay una copia de seguridad, se pierde absolutamente todo: todo el historial del proyecto, con la posible excepción de varias versiones funcionales guardadas en las máquinas de trabajo de los usuarios.

CVS

CVS (Sistema de Versiones Concurrentes) sigue siendo el sistema más utilizado, pero está perdiendo popularidad rápidamente debido a deficiencias que comentaré a continuación. Dick Grune desarrolló CVS a mediados de los años 1980. Para almacenar archivos individuales, CVS (así como RCS) utiliza archivos en formato RCS, pero le permite administrar grupos de archivos ubicados en directorios. CVS también utiliza una arquitectura cliente-servidor en la que toda la información de la versión se almacena en el servidor. El uso de una arquitectura cliente-servidor permite que CVS sea utilizado incluso por equipos de usuarios distribuidos geográficamente donde cada usuario tiene su propio directorio de trabajo con una copia del proyecto. Como sugiere el nombre, los usuarios pueden compartir el sistema.

Los posibles conflictos al cambiar un mismo archivo se resuelven por el hecho de que el sistema sólo permite realizar cambios en la versión más reciente del archivo. Por lo tanto, siempre se recomienda actualizar su copia de trabajo de los archivos antes de cargar los cambios en caso de posibles cambios conflictivos. Al actualizar, el sistema realiza cambios en la copia de trabajo automáticamente y solo en caso de que se requieran cambios contradictorios en una de las ubicaciones del archivo. corrección manual lugares de conflicto.

CVS también le permite mantener múltiples líneas de desarrollo de proyectos utilizando ramas de desarrollo. Por lo tanto, como se mencionó anteriormente, puede corregir errores en la primera versión del proyecto y simultáneamente desarrollar nuevas funciones.

CVS se utilizó en una gran cantidad de proyectos, pero, por supuesto, no estuvo exento de deficiencias, que luego llevaron a la aparición del siguiente sistema en consideración. Veamos las principales desventajas:

• Dado que las versiones se almacenan en archivos RCS, no es posible guardar versiones del directorio. La forma estándar de solucionar esto es guardar algún archivo (por ejemplo, README.txt) en un directorio;
• Mover o cambiar el nombre de archivos no está sujeto al control de versiones. La forma estándar de hacer esto es copiar primero el archivo, eliminar el antiguo usando el comando cvs remove y luego agregarlo con su nuevo nombre usando el comando cvs add;

Subversión

Subversion (SVN) fue desarrollado en 2000 por iniciativa de CollabNet. SVN se desarrolló originalmente como un "mejor CVS" y el objetivo principal de los desarrolladores era corregir los errores cometidos en el diseño del CVS manteniendo una interfaz similar. SVN, al igual que CVS, utiliza una arquitectura cliente-servidor. Los cambios más significativos en comparación con CVS incluyen:

• Cambios atómicos (compromiso). Si se interrumpe el procesamiento de confirmación, no se realizarán cambios.
• Cambiar el nombre, copiar y mover archivos conserva todo el historial de cambios.
• Los directorios, enlaces simbólicos y metadatos están sujetos a control de versiones.
• Almacenamiento de cambios eficiente para archivos binarios.

Sistemas de control de versiones distribuidos

Y en esta situación entran en juego los sistemas de control de versiones distribuidas (DVCS). En sistemas como Git, Mercurial, Bazaar o Darcs, los clientes no se limitan a consultar las últimas versiones de los archivos, sino que copian todo el repositorio. Por lo tanto, en el caso de que el servidor a través del cual pasaba el trabajo "muera", cualquier repositorio del cliente se puede copiar nuevamente al servidor para restaurar la base de datos. Cada vez que un cliente retira una nueva versión de los archivos, crea una copia completa de todos los datos para sí mismo.

Además, la mayoría de estos sistemas le permiten trabajar con múltiples repositorios remotos, por lo que puede trabajar de manera diferente con diferentes grupos de personas en el mismo proyecto al mismo tiempo. Así, en un proyecto se pueden realizar simultáneamente varios tipos de procesos de trabajo, lo que es imposible en sistemas centralizados.

¿Por qué se necesitan sistemas distribuidos?

Como sugiere el nombre, una de las ideas principales de los sistemas distribuidos es la ausencia de un almacén de versiones central claramente designado: un repositorio. En el caso de sistemas distribuidos, un conjunto de versiones se puede distribuir total o parcialmente entre varios repositorios, incluidos los remotos. Este modelo encaja perfectamente en el trabajo de equipos distribuidos, por ejemplo, un equipo de desarrolladores distribuidos por todo el mundo trabajando en el mismo proyecto de código abierto. El desarrollador de dicho equipo puede descargar toda la información de la versión y luego trabajar sólo en la máquina local. Tan pronto como se logra el resultado de una de las etapas del trabajo, los cambios pueden cargarse en uno de los repositorios centrales o publicarse para su visualización en el sitio web del desarrollador o en la lista de correo. Otros participantes del proyecto, a su vez, podrán actualizar su copia del repositorio de versiones con nuevos cambios o probar los cambios publicados en una rama de desarrollo de prueba separada. Desafortunadamente, sin una buena organización del proyecto, la falta de un repositorio central puede ser una desventaja de los sistemas distribuidos. Si en el caso de los sistemas centralizados siempre hay un repositorio común desde donde se puede obtener la última versión del proyecto, entonces en el caso de los sistemas distribuidos es necesario decidir organizativamente cuál de las ramas del proyecto será la principal. ¿Por qué un sistema de control de versiones distribuido sería de interés para alguien que ya está utilizando un sistema centralizado, como Subversion? Todo trabajo implica tomar decisiones, y en la mayoría de los casos es necesario probar diferentes opciones: cuando se trabaja con sistemas de control de versiones, considerar diferentes opciones y trabajar en grandes cambios sirven las ramas de desarrollo. Aunque este es un concepto bastante natural, no es fácil de usar en Subversion. Además, todo se vuelve más complicado en el caso de múltiples fusiones secuenciales de una rama a otra; en este caso, es necesario indicar con precisión las versiones inicial y final de cada cambio para evitar conflictos y errores. Para los sistemas de control de versiones distribuidas, las ramas de desarrollo son uno de los conceptos fundamentales; en la mayoría de los casos, cada copia de un almacén de versiones es una rama de desarrollo. Así, el mecanismo de fusión de cambios de una rama a otra en el caso de sistemas distribuidos es uno de los principales, lo que permite a los usuarios realizar un menor esfuerzo en el uso del sistema.

Breve descripción de los SUV distribuidos populares.

• Git es un sistema de control de versiones distribuido desarrollado por Linus Torvalds. Inicialmente, Git estaba destinado a usarse en el proceso de desarrollo del kernel de Linux, pero luego comenzó a usarse en muchos otros proyectos, como, por ejemplo, X.org y Ruby on Rails, Drupal. Actualmente, Git es el sistema distribuido más rápido que utiliza el almacén de revisiones más pequeño. Pero al mismo tiempo, para los usuarios que migran, por ejemplo, desde Subversion, la interfaz de Git puede parecer complicada;
• Mercurial es un sistema distribuido escrito en Python con varias extensiones en C. Los proyectos que utilizan Mercurial incluyen Mozilla y MoinMoin.
• Bazaar es un sistema desarrollado por Canonical, conocido por su distribución de ubuntu y el sitio web https://launchpad.net/. El sistema está escrito principalmente en Python y lo utilizan proyectos como MySQL.
• Codeville es un sistema distribuido escrito en Python que utiliza un algoritmo innovador para combinar cambios (fusionar). El sistema se utiliza, por ejemplo, en el desarrollo del cliente BitTorrent original.
• Darcs es un sistema de control de versiones distribuido escrito en Haskell, utilizado, por ejemplo, por el proyecto Buildbot.
• Monotone es un sistema escrito en C++ y que utiliza SQLite como almacenamiento de revisiones.

Descripción general de los sistemas de control de versiones

Los sistemas de control de versiones se han convertido en una parte integral de la vida no solo de los desarrolladores de software, sino también de todas las personas que se enfrentan al problema de gestionar información que cambia intensamente y quieren hacerles la vida más fácil. Como resultado, ha surgido una gran cantidad de productos diferentes que ofrecen amplias capacidades y herramientas para el control de versiones. Este artículo analizará brevemente los más populares y enumerará sus ventajas y desventajas.

A modo de comparación, se eligieron los sistemas de control de versiones más comunes: RCS, CVS, Subversion, Aegis, Monoton, Git, Bazaar, Arch, Perforce, Mercurial, TFS.

RCS es un sistema de gestión de revisiones de versiones.
(www.gnu.org/software/rcs/rcs.html)

Comencemos nuestra revisión con uno de los primeros sistemas de control de versiones: RCS (Revision Control System), desarrollado en 1985. Reemplazó al SCCS (Sistema de control de código fuente), un sistema de control de versiones popular en ese momento.

Por el momento, RCS está siendo reemplazado activamente por el sistema de control de versiones más potente CVS, pero sigue siendo bastante popular y forma parte del proyecto GNU.

RCS le permite trabajar sólo con archivos individuales, creando un historial de cambios para cada uno. Para archivos de texto No se guardan todas las versiones del archivo, solo la última versión y todos los cambios realizados. RCS también puede rastrear cambios en archivos binarios, pero cada cambio se almacena como una versión separada del archivo.

Cuando un usuario realiza cambios en un archivo, el archivo permanece bloqueado para todos los demás. No pueden solicitarlo desde el repositorio para editarlo hasta que el primer usuario finalice y confirme los cambios.

Veamos las principales ventajas y desventajas del sistema de control de versiones RCS.

Ventajas:

1. RCS: fácil de usar y muy adecuado para familiarizarse con los principios de funcionamiento de los sistemas de control de versiones.

2. Bueno para respaldo archivos separados, que no requieren cambios frecuentes por parte de un grupo de usuarios.

3. Ampliamente distribuido y preinstalado en la mayoría de los sistemas operativos de distribución gratuita.

Defectos:

1. Realiza un seguimiento de los cambios solo en archivos individuales, lo que no permite su uso para el control de versiones. grandes proyectos.

2. No permite que varios usuarios realicen cambios en el mismo archivo al mismo tiempo.

3. Baja funcionalidad en comparación con los sistemas de control de versiones modernos.

Conclusiones:

El sistema de control de versiones RCS proporciona un conjunto de herramientas demasiado débil para gestionar proyectos desarrollados y sólo es adecuado para familiarizarse con la tecnología de control de versiones o mantener un pequeño historial de reversiones de archivos individuales.

CVS es un sistema de control de versiones paralelo.
(www.nongnu.org/cvs)

El Sistema de Versiones Concurrentes es un desarrollo lógico del sistema de control de revisiones (RCS), que utiliza sus estándares y algoritmos de control de versiones, pero es mucho más funcional y le permite trabajar no solo con archivos individuales, sino también con proyectos completos.

CVS se basa en tecnología cliente-servidor que interactúa a través de una red. El cliente y el servidor también pueden estar ubicados en la misma máquina si solo hay una persona trabajando en el proyecto o si se requiere control de versión local.

CVS funciona de la siguiente manera. La última versión y todos los cambios realizados se almacenan en el repositorio del servidor. Los clientes que se conectan al servidor comprueban las diferencias versión local desde la última versión guardada en el repositorio, y si hay diferencias, súbelas a tu proyecto local. Si es necesario, resuelva los conflictos y realice los cambios necesarios en el producto que se está desarrollando. Después de esto, todos los cambios se cargan en el repositorio del servidor. CVS, si es necesario, le permite retroceder a la versión deseada del proyecto que se está desarrollando y gestionar varios proyectos simultáneamente.

A continuación se detallan las principales ventajas y desventajas del sistema de control de versiones paralelo.

Ventajas:

1. Varios clientes pueden trabajar en el mismo proyecto al mismo tiempo.

2. Le permite administrar no solo un archivo, sino proyectos completos.

3. Tiene una gran cantidad de interfaces gráficas convenientes que pueden satisfacer a casi cualquier persona, incluso a los gustos más exigentes.

4. Ampliamente utilizado y viene de forma predeterminada con la mayoría de los sistemas operativos Linux.

5. Al descargar archivos de prueba del repositorio, solo se transfieren los cambios y no el archivo completo.

Defectos:

1. Cuando mueve o cambia el nombre de un archivo o directorio, todos los cambios asociados con este archivo o directorio se pierden.

2. Dificultades a la hora de mantener varias ramas paralelas de un mismo proyecto.

3. Soporte de fuentes limitado.

4. Para cada cambio en un archivo binario, se guarda la versión completa del archivo, no solo el cambio realizado.

5. El archivo modificado siempre se transfiere completamente del cliente al servidor.

6. Operaciones que consumen muchos recursos, ya que requieren acceso frecuente al repositorio y las copias guardadas tienen cierta redundancia.

Conclusiones:

Aunque CVS está desactualizado y tiene fallas graves, sigue siendo uno de los sistemas de control de versiones más populares y es excelente para administrar proyectos pequeños que no requieren múltiples versiones paralelas que deben fusionarse periódicamente. CVS se puede recomendar como paso intermedio en el dominio del funcionamiento de los sistemas de control de versiones, lo que lleva a tipos de programas más potentes y modernos.

Sistema de control de versiones Subversion.
(www.subversion.tigris.org)

Subversion es un sistema de control de versiones centralizado creado en el año 2000 y basado en tecnología cliente-servidor. Tiene todas las ventajas de CVS y resuelve sus principales problemas (renombrar y mover archivos y directorios, trabajar con archivos binarios, etc.). A menudo se le llama por el nombre de la parte del cliente: SVN.

El principio de trabajar con Subversion es muy similar a trabajar con CVS. Los clientes copian los cambios del repositorio y los combinan en el proyecto local del usuario. Si surgen conflictos cambios locales y los cambios guardados en el repositorio, dichas situaciones se resuelven manualmente. Luego se realizan cambios en el proyecto local y el resultado se guarda en el repositorio.

Cuando se trabaja con archivos que no permiten fusionar cambios, se puede utilizar el siguiente principio:

1. El archivo se descarga del repositorio y se bloquea (está prohibido descargarlo del repositorio).

2. Se realizan los cambios necesarios.

3. El archivo se carga en el repositorio y se desbloquea (otros clientes pueden descargarlo del repositorio).

En gran parte debido a su simplicidad y similitud en la gestión con CVS, pero principalmente debido a su amplia funcionalidad, Subversion compite con éxito con CVS e incluso lo desplaza con éxito.

Sin embargo, Subversion también tiene sus inconvenientes. Veamos sus fortalezas y debilidades para compararlos con otros sistemas de control de versiones.

Ventajas:

1. Sistema de mando similar al CVS.

2. La mayoría de las funciones de CVS son compatibles.

3. Variado interfaces gráficas Y trabajo conveniente desde la consola.

4. Se realiza un seguimiento del historial de cambios en archivos y directorios incluso después de cambiarles el nombre y moverlos.

5. Alta eficiencia al trabajar con archivos de texto y binarios.

6. Soporte integrado en muchas herramientas de desarrollo integradas como KDevelop, Zend Studio y muchas otras.

7. Posibilidad de crear copias espejo del repositorio.

8. Dos tipos de repositorio: una base de datos o un conjunto de archivos normales.

9. Posibilidad de acceder al repositorio a través de Apache utilizando el protocolo WebDAV.

10. Disponibilidad de un mecanismo conveniente para crear etiquetas y ramas de proyectos.

11. Puede asociar un conjunto específico de propiedades a cada archivo y directorio, facilitando la interacción con el sistema de control de versiones.

12. La distribución generalizada permite resolver rápidamente la mayoría de los problemas que surgen al recurrir a los datos acumulados por la comunidad de Internet.

Defectos:

1. Una copia completa del repositorio se almacena en la computadora local en archivos ocultos, lo que requiere una cantidad de memoria bastante grande.

2. Hay problemas al cambiar el nombre de los archivos si un archivo cuyo nombre cambió localmente por un cliente fue modificado al mismo tiempo por otro cliente y subido al repositorio.

3. Escaso apoyo para fusionar ramas de proyectos.

4. Dificultades para eliminar completamente información sobre los archivos incluidos en el repositorio, ya que siempre contiene información sobre cambios anteriores en el archivo y no existen disposiciones para fondos regulares para eliminar completamente los datos del archivo del repositorio.

Conclusiones:

Subversion es un moderno sistema de control de versiones que cuenta con una amplia gama de herramientas para satisfacer cualquier necesidad de gestionar versiones de proyectos mediante un sistema de control centralizado. Hay muchos recursos en Internet dedicados a las funciones de Subversion, que le permiten resolver rápida y eficientemente todos los problemas que surgen durante su trabajo.

La facilidad de instalación, la preparación para el trabajo y las amplias capacidades permiten a Subversion ocupar una de las posiciones de liderazgo en la carrera competitiva de los sistemas de control de versiones.

Sistema de control de versiones Aegis.

Aegis, creado por Peter Miller en 1991, es la primera alternativa a los sistemas de control de versiones centralizados. Todas las operaciones en él se realizan a través del sistema de archivos Unix. Desafortunadamente, Aegis no tiene soporte de red incorporado, pero las interacciones se pueden realizar utilizando protocolos como NFS, HTTP, FTP.

La característica principal de Aegis es la forma en que controla los cambios realizados en el repositorio.

En primer lugar, antes de realizar cualquier cambio, deben pasar una serie de pruebas. Y si las innovaciones en el código fuente del programa no pasan las pruebas, entonces es necesario agregar nuevas pruebas o corregir posibles errores en el código fuente.

En segundo lugar, antes de realizar cambios en la rama principal del proyecto que se está desarrollando, estos deben ser aprobados por un revisor.

En tercer lugar, se proporciona una jerarquía de acceso al repositorio, basada en el sistema de derechos de acceso a los archivos de los sistemas operativos tipo Unix.

Todo esto hace que utilizar el sistema de control de versiones Aegis sea confiable, pero extremadamente difícil, e incluso una buena documentación no lo hace mucho más fácil.

Destaquemos las principales ventajas y desventajas del sistema de control de versiones Aegis.

Ventajas:

1. Control confiable de la exactitud de los cambios cargados.

2. La capacidad de proporcionar diferentes niveles de acceso a los archivos del repositorio, lo que proporciona un nivel de seguridad decente.

3. Documentación de alta calidad.

4. Posibilidad de cambiar el nombre de los archivos guardados en el repositorio sin perder el historial de cambios.

5. Capacidad para trabajar con un repositorio local, si no está disponible acceso a la red al repositorio principal.

Defectos:

1. Falta de soporte integrado para la interacción en red.

2. Dificultad para configurar y trabajar con el repositorio.

3. Interfaces gráficas débiles.

Conclusiones:

La complejidad de Aegis puede disuadir a los usuarios de utilizar sistemas de control de versiones, por lo que no se recomienda como referencia ni para proyectos de software pequeños. Sin embargo, tiene una serie de ventajas que pueden resultar útiles en algunas situaciones específicas, especialmente cuando se requiere un control estricto sobre la calidad del software que se está desarrollando.

Sistema de control de versiones monótonas.
(monotone.ca)

Monotone es otro sistema de control de versiones descentralizado desarrollado por Graydon Hoem. En él, cada cliente es responsable de sincronizar las versiones del producto que está desarrollando con otros clientes.

Trabajar con este sistema de control de versiones es bastante simple y muchos de los comandos son similares a los comandos utilizados en Subversion y CVS. Las diferencias radican principalmente en la organización de las ramas fusionadas de proyectos de diferentes desarrolladores.

Trabajar con Monotone se estructura de la siguiente manera. Primero, se crea una base de datos del proyecto SQLite y se generan claves utilizando el algoritmo hash SHA1 (Secure Hash Algorithm 1).

Luego, cuando el usuario edita el proyecto, todos los cambios se guardan en esta base de datos, de forma similar a guardar cambios en el repositorio de otros sistemas de control de versiones.

Para sincronizar un proyecto con otros usuarios es necesario:

Exporte la clave (código hash de la última versión del proyecto) y reciba claves similares de otros clientes.

Ahora todos los registrados de esta manera pueden sincronizar el desarrollo con sus colegas mediante un simple conjunto de comandos.

Resumamos las ventajas y desventajas del sistema de control de versiones Monotone.

Ventajas:

1. Un conjunto de comandos simple y claro, similar a los comandos de Subversion y CVS.

2. Admite cambiar el nombre y mover archivos y directorios.

3. Documentación de alta calidad, que facilita enormemente el uso del sistema de control de versiones.

Defectos:

1. Baja velocidad.

2. Falta de poderosos conchas gráficas.

3. Posibles (pero extremadamente bajas) coincidencias del código hash de revisiones que difieren en contenido.

Conclusiones:

Monótono es poderoso y herramienta útil para gestionar versiones del proyecto que se está desarrollando. El conjunto de comandos está bien pensado y es intuitivo, especialmente conveniente para usuarios acostumbrados a trabajar con Subversion y CVS. Una documentación completa y bien diseñada le permitirá acostumbrarse rápidamente y utilizar todas las funciones de Subversion en todo su potencial.

Sin embargo, relativamente baja velocidad El trabajo y la falta de potentes gráficos pueden dificultar un poco el trabajo con proyectos grandes. Por lo tanto, si necesita un sistema de control de versiones para admitir productos grandes y complejos, debería buscar en Git o Mercurial.

Sistema de control de versiones Git.
(www.git-scm.com)

Desde febrero de 2002, la mayoría de los programadores comenzaron a utilizar el sistema de control de versiones BitKeeper para desarrollar el kernel de Linux. Durante bastante tiempo no hubo problemas con él, pero en 2005 Larry McVoy (desarrollador de BitKeeper) retiró la versión gratuita del programa.

Es imposible desarrollar un proyecto a escala Linux sin un sistema de control de versiones potente y confiable. Uno de los candidatos y el proyecto más adecuado era el sistema de control de versiones Monotine, pero Torvalds Linus no estaba satisfecho con su velocidad. Dado que las peculiaridades de la organización Monatone no permitían un aumento significativo en la velocidad de procesamiento de datos, el 3 de abril de 2005 Linus comenzó a desarrollar propio sistema control de versiones - Git.

Casi simultáneamente con Linus (tres días después), al desarrollo. nuevo sistema Matt Makal también inició el control de versiones. Matt llamó a su proyecto Mercurial, pero hablaremos de eso más adelante, pero ahora volvamos al sistema de control de versiones distribuido Git.

Git es un sistema de control de versiones flexible y distribuido (sin un solo servidor) que brinda muchas oportunidades no solo a los desarrolladores de software, sino también a los escritores para cambiar, agregar y rastrear cambios en "manuscritos" e historias, y para que los maestros los ajusten. y desarrollar un curso de conferencias y administradores para la documentación y para muchas otras áreas que requieren gestión del historial de cambios.

Cada desarrollador que utiliza Git tiene su propio repositorio local, lo que permite el control de versiones local. Luego, los datos guardados en el repositorio local se pueden intercambiar con otros usuarios.

A menudo, cuando trabajas con Git, creas un repositorio central con el que otros desarrolladores sincronizan. Un ejemplo de organización de un sistema con un repositorio central es el proyecto de desarrollo del kernel de Linux (http://www.kernel.org).

En este caso, todos los participantes del proyecto llevan a cabo su desarrollo local y descargan libremente las actualizaciones desde el repositorio central. Cuando trabajo necesario completado y depurado por los participantes individuales del proyecto, ellos, después de que el propietario del repositorio central certifique que el trabajo realizado es correcto y está actualizado, cargan sus cambios en el repositorio central.

Tener repositorios locales también aumenta significativamente la confiabilidad del almacenamiento de datos, ya que si uno de los repositorios falla, los datos se pueden recuperar fácilmente desde otros repositorios.

El trabajo en versiones de un proyecto en Git se puede llevar a cabo en varias ramas, que luego se pueden fusionar, destruir, revertir y expandir total o parcialmente fácilmente a más y más ramas nuevas del proyecto.

Podemos discutir las capacidades de Git durante mucho tiempo, pero para abreviar y facilitar la comprensión, presentaremos las principales ventajas y desventajas de este sistema de control de versiones.

Ventajas:

1. Sistema confiable comparar revisiones y comprobar la exactitud de los datos, basándose en el algoritmo hash SHA1 (Secure Hash Algorithm 1).

2. Sistema flexible para ramificar proyectos y fusionar sucursales entre sí.

3. La presencia de un repositorio local que contiene información completa sobre todos los cambios le permite mantener un control total de la versión local y cargar solo cambios completamente verificados en el repositorio principal.

4. Alta productividad y velocidad.

5. Conjunto de comandos conveniente e intuitivo.

6. Muchos shells gráficos que le permiten trabajar con Git de forma rápida y eficiente.

7. La capacidad de crear puntos de control en los que los datos se guardan sin compresión delta, pero de forma completa. Esto le permite reducir la velocidad de recuperación de datos, ya que se toma como base el punto de control más cercano y la recuperación se realiza a partir de él. Si faltaran puntos de control, los grandes proyectos podrían tardar horas en recuperarse.

8. Amplia distribución, fácil accesibilidad y documentación de alta calidad.

9. La flexibilidad del sistema le permite configurarlo cómodamente e incluso crear controles de sistema especializados o interfaces de usuario basadas en git.

10. Acceso universal a la red mediante protocolos http, ftp, rsync, ssh, etc.

Defectos:

1. Unix - orientación. Actualmente no existe una implementación madura de Git que sea compatible con otros sistemas operativos.

2. Posibles (pero extremadamente bajas) coincidencias del código hash de revisiones que difieren en contenido.

3. No se realiza un seguimiento de los cambios en archivos individuales, sino solo en todo el proyecto, lo que puede resultar inconveniente cuando se trabaja con proyectos grandes que contienen muchos archivos desconectados.

4. Al crear inicialmente un repositorio y sincronizarlo con otros desarrolladores, la descarga de datos llevará bastante tiempo, especialmente si el proyecto es grande, ya que es necesario copiar todo el repositorio a la computadora local.

Conclusiones:

Git es un sistema de control de versiones flexible, conveniente y potente que puede satisfacer a la gran mayoría de usuarios. Las deficiencias existentes se están eliminando gradualmente y no causan problemas graves a los usuarios. Si está ejecutando un proyecto grande, geográficamente remoto, y aún más, si a menudo tiene que desarrollar software sin acceso a otros desarrolladores (por ejemplo, no quiere perder el tiempo volando de un país a otro o viajando a funciona), puede realizar cualquier cambio y guardarlo en el repositorio local, revertirlo, cambiar entre ramas, etc.). Git es uno de los líderes en sistemas de control de versiones.

Sistema de control de versiones Mercurial.
(mercurial.selenic.com)

El sistema de control de versiones distribuido Mercurial fue desarrollado por Matt Macal en paralelo con el sistema de control de versiones Git creado por Torvalds Linus.

Originalmente fue creado para gestión eficaz grandes proyectos bajo Linux, y por lo tanto se centró en rápido y operación confiable con grandes repositorios. Por el momento, Mercurial está adaptado para funcionar en Windows, Mac OS X y la mayoría de los sistemas Unix.

La mayor parte del sistema de control de versiones está escrito en Python, y sólo áreas separadas Los programas que requieren mayor velocidad están escritos en C.

Las revisiones se identifican según el algoritmo hash SHA1 (Secure Hash Algorithm 1); sin embargo, también es posible asignar números individuales a las revisiones;

Al igual que en git, admite la capacidad de crear ramas de proyectos y luego fusionarlas.

Se utiliza para la interacción entre clientes. protocolos HTTP, HTTPS o SSH.

El conjunto de comandos es simple e intuitivo, muy parecido a los comandos de Subversion. También hay una serie de shells gráficos y acceso al repositorio a través de una interfaz web. También es importante contar con utilidades que permitan importar repositorios de muchos otros sistemas de control de versiones.

Veamos las principales ventajas y desventajas de Mercurial.

Ventajas:

1. Procesamiento rápido datos.

2. Soporte multiplataforma.

3. Capacidad para trabajar con varias ramas del proyecto.

4. Fácil de usar.

5. Capacidad para convertir repositorios de otros sistemas de soporte de versiones, como CVS, Subversion, Git, Darcs, GNU Arch, Bazaar, etc.

Defectos:

1. Posibles (pero extremadamente bajas) coincidencias del código hash de revisiones que difieren en contenido.

2. Centrado en trabajar en la consola.

Conclusiones:

Una interfaz simple y pulida, un conjunto de comandos y la capacidad de importar repositorios desde otros sistemas de control de versiones harán que la transición a Mercurial y el aprendizaje de las características principales sean sencillos y rápidos. Es poco probable que esto lleve más de unos pocos días.

Su confiabilidad y velocidad permiten que se utilice para el control de versiones de grandes proyectos. Mercurial lo hace todo competidor digno idiota.

Sistema de control de versiones de Bazar.
(bazar.canonical.com)

Bazaar es un sistema de control de versiones distribuido y disponible gratuitamente desarrollado con el apoyo de Canonical Ltd. Está escrito en Python y se ejecuta en los sistemas operativos Linux, Mac OS X y Windows.

A diferencia de Git y Mercurial, que fueron creados para controlar las versiones del kernel del sistema operativo Linux y, por lo tanto, se centraron en el máximo rendimiento al trabajar con una gran cantidad de archivos, Bazaar se centró en una interfaz de usuario cómoda y amigable. La optimización de la velocidad de trabajo se llevó a cabo ya en la segunda etapa, cuando ya habían aparecido las primeras versiones del programa.

Como ocurre con muchos otros sistemas de control de versiones, el sistema de comandos de Bazaar es muy similar a los comandos CVS o Subversion, lo que, sin embargo, no es sorprendente, ya que proporciona una forma cómoda, sencilla e intuitiva. interfaz clara interacción con el programa.

Es bueno que se preste gran atención al trabajo con ramas de proyectos (creación, fusión de ramas, etc.), lo cual es muy importante a la hora de desarrollar proyectos serios y permite realizar mejoras y experimentos sin la amenaza de perder la versión principal del software. .

Una gran ventaja de este sistema de control de versiones es la capacidad de trabajar con repositorios de otros sistemas de control de versiones, como Subversion o Git.

Resumamos brevemente las ventajas y desventajas más significativas de este sistema de control de versiones.

Ventajas:

1. Soporte multiplataforma.

2. Interfaz cómoda e intuitiva.

3. Trabajo sencillo con ramas de proyectos.

4. Capacidad para trabajar con repositorios de otros sistemas de control de versiones.

5. Excelente documentación.

6. Interfaz gráfica conveniente.

7. Extrema flexibilidad, permitiéndole adaptarse a las necesidades de un usuario específico.

Defectos:

1. Menor velocidad en comparación con git y mercurial, pero esta situación se está corrigiendo gradualmente.

2. Para una funcionalidad completa, es necesario instalar una cantidad suficientemente grande de complementos para revelar completamente todas las capacidades del sistema de control de versiones.

Conclusiones:

Bazaar es un conveniente sistema de control de versiones con una interfaz agradable. Bueno para los usuarios que se sienten desanimados ante la perspectiva de trabajar con la línea de comandos. Muchos opciones adicionales y las extensiones le permitirán personalizar el programa para adaptarlo a sus necesidades. La similitud del sistema de comando con Git y Subversion, y la capacidad de trabajar directamente con sus repositorios, harán que la transición a Bazaar sea rápida y sencilla. El éxito del bazar también se evidencia en el hecho de que se utiliza Desarrolladores de Ubuntu Linux.

Sistema de control de versiones de arco.

Arch es un sistema de control de versiones distribuido creado por Tom Lord. Originalmente fue creado para resolver los problemas de CVS, lo cual lograron.

Arch realiza operaciones atómicas para guardar los cambios en el repositorio, es decir. elimina la situación de descargar un repositorio, cuando algunos de los cambios se han descargado y otros aún no han tenido tiempo de descargarse.

Se admite la capacidad de bifurcar versiones de proyectos y fusionar ramas individuales, cambiar el nombre y mover archivos y directorios mientras se mantiene el historial de cambios, y muchas otras características interesantes.

No requiere servicio especial para un repositorio de red y puede utilizar protocolos como FTP, SFTP o WebDAV, etc.

Pero, desafortunadamente, sólo es compatible con sistemas UNIX; sin embargo, transferir Arch a otros sistemas operativos no debería ser difícil;

Es difícil notar cualidades fundamentalmente mejores en comparación con otros sistemas de control de versiones distribuidos, como git, mercurial, bazaar, por lo que si puede elegir, es mejor usar algo más potente y extendido.

Sistema de control de versiones Perforce.
(www.perforce.com)

Continuemos nuestra revisión de los sistemas de control de versiones y pasemos a programas comerciales. Comencemos con el sistema de control de versiones centralizado: Perforce, desarrollado por Perforce Software.

El sistema Perforce tiene una organización cliente-servidor y permite gestionar simultáneamente varios proyectos, creando su propio repositorio para cada proyecto.

Perforce es un sistema multiplataforma. Hay versiones que pueden ejecutarse en los sistemas operativos Unix, Mac OS X y Microsoft Windows.

Para trabajar con el sistema de control de versiones, puede utilizar tanto la consola como una interfaz gráfica especialmente diseñada.

Una ventaja importante de Perforce es la capacidad de integrarse con muchas herramientas y aplicaciones de desarrollo de software como Autodesk 3D Studio Max, Maya, Adobe Photoshop, oficina de microsoft, Eclipse, emacs y muchos otros.

La compatibilidad con la capacidad de crear ramas de versiones de proyectos, administrarlas de manera flexible, fusionarlas y retroceder a revisiones anteriores hace de Perforce un sistema completamente competitivo y contribuye a su amplia distribución. Sin embargo, se trata de un producto comercial, lo que reduce un poco su alcance y limita su difusión. Se utiliza principalmente en grandes empresas comerciales, para lo cual no solo es importante la funcionalidad, sino también el soporte técnico oportuno.

Sistema de control de versiones de Team Foundation Server.
(msdn.microsoft.com/en-us/library/ms364061.aspx)

Estrictamente hablando, Team Foundation Server (TFC) no puede llamarse simplemente un sistema de control de versiones: es una especie de solución integral, que incluye un sistema de control de versiones, un sistema de recopilación de datos, generación de informes y otras funciones útiles.

Un proyecto administrado cuando se trabaja con TFC consta de ramas de código fuente del proyecto, conjuntos de informes y elementos personalizados. Al crear un proyecto, sus parámetros se seleccionan de antemano, que usted puede elegir usted mismo o utilizar plantillas. Las plantillas le permiten determinar el camino del desarrollo del proyecto, hacerlo flexible o formalizarlo rígidamente, establecer una estrategia de desarrollo y tener en cuenta los documentos e informes necesarios.

TFC se integra fácilmente con Microsoft Excel y Microsoft Project, lo que facilita mucho la creación y el seguimiento de elementos controlados del proyecto.

Como sistema de control de versiones, TFC le permite:

Editar archivos de proyecto de forma colaborativa;

Resolver conflictos;

Cree ramas de proyecto y luego combínelas;

Gestionar el acceso al repositorio;

Retroceder a versiones anteriores;

Crear cambios diferidos: cambios que no se agregan directamente al repositorio, pero que otros usuarios pueden ver, y estos cambios solo se pueden descargar obteniendo un permiso especial del propietario de los cambios;

Marque versiones individuales de archivos en el repositorio y agrúpelas;

Para guardar datos y repositorios de proyectos desarrollados se utilizan bases de datos datos SQL Servidor 2005.

TFC es una herramienta poderosa y conveniente que le permite no solo administrar las versiones del código fuente, sino también organizar completamente todo el ciclo de desarrollo del proyecto, desde la escritura del programa hasta su documentación. Sin embargo, este poderoso y sistema complejo más adecuado para grandes proyectos que requieren una gestión de desarrollo compleja y exhaustiva. Si tiene un desarrollo pequeño, entonces tiene sentido utilizar una herramienta menos poderosa, o mejor aún, una de distribución gratuita, ya que esto le ahorrará tiempo, dinero y nervios.

Generalización.

Una gran selección de sistemas de control de versiones le permite satisfacer cualquier requisito y organizar su trabajo de la manera que necesita. Sin embargo, entre la variedad de sistemas hay líderes claros. Por lo tanto, si necesita gestionar un proyecto enorme que consta de decenas de miles de archivos y en el que trabajan miles de personas, lo mejor es elegir Git o Mercurial. Si lo principal para usted es una interfaz conveniente y el proyecto que se está desarrollando no es muy grande, entonces es preferible el sistema Bazaar.

Para programadores solitarios o proyectos pequeños que no requieren ramificaciones o creación de múltiples versiones, Subversion es su mejor opción.

Pero en última instancia, la elección es una cuestión de gustos, ya que ahora existen muchos sistemas de control de versiones que le brindarán todo lo que necesita. Así que elige y no te arrepentirás. Los sistemas de control de versiones son software absolutamente esencial para todos los desarrolladores y más.