investigación sobre las ventajas y desventajas las diferentes herramientas de control de versiones actualmente utilizadas en el mercado
Un controlador de versiones es un sistema que nos permite guardar un registro de las modificaciones que realizamos sobre un fichero o conjunto de ficheros a lo largo del tiempo de tal manera que sea posible recuperar versiones específicas más adelante. Habitualmente se utiliza en entornos de desarrollo de software, pero puede resultar de gran utilidad para cualquier persona que necesite un control robusto sobre la tarea que está realizando.
La mayoría de la gente utilizamos algún sistema de control de versiones sin ser conscientes de ello. El ejemplo más claro es al editar cualquier tipo de fichero en servicios de almacenamiento en “la nube” como Google Drive o Dropbox.. Consultar fuente....
El objetivo de la investigacion es conocer sobre las ventajas y desventajas de las diferentes herramientas de control de versiones, actualmente utilizadas en el mercado laboral y disponibles en el ambiente informático y que son comúnmente utilizadas en el proceso de construcción de software para desarrollar programas con una infraestructura para el desarrollo sostenible de los sistemas de informacion para brindar un software mucho mas especializado
Muy versátil y configurable.
Distribuido, podemos hace commits en nuestra maquina local, por lo que podemos seguir trabajando sin conexión a Internet subir los cambios mas tarde.
Rápido, la mayoría de operaciones son locales, resolución de conflictos a travez de herramientas mergetool y el editor meld.
Seguro, se puede trabajar incluso si el servidor esta caído sin perder tiempo de trabajo.
La posibilidad de ver rápidamente la historia del proyecto con el comando git log.
Curva de aprendizaje para los que vienen de SVN.
Muchos comandos y el significado de los comandos.
Disponibilidad, el código esta en un solo repositorio.
Complejidad, recomendado para proyectos grandes.
Utiliza arquitectura cliente- servidor.
El servidor guarda las versiones y el historial.
Los cliente se conectan y hacen una copia completa del proyecto.
Funciona en cualquier sistema operativo.
Varios personas pueden sacar una copia al mismo tiempo.
Puede mantener distintas ramas de un Proyecto.
No soporta refactorización de sistemas de forma automática o versionadas.
Limitada para UTF-8 Unicode o archivos con contenido diferecnte ACII.
El protocolo no soporta eliminación de directorios o re nombrarlos.
Visual Studio carece de soporte nativo a CVS.
Se sigue la historia de los archivos y directorios a través de copias y renombrados.
Modificaciones atómicas.
La creacionde branch, y tags son operaciones eficientes.
Se envían sólo las diferencias en ambas direcciones.
Maneja eficazmenta los archivos binarios.
Permite el bloqueo de archivos.
El manejo de cambio de nombres de archivos no es completo. Lo maneja como la suma de una operación de copia y una de borrado.
No resuelve el problema de aplicar repetidamente parches entre ramas, no facilita llevar la cuenta de qué cambios se han realizado. esto se resuelve siendo cuidadoso con los mensajes de commit.
Rápido escalable.
Mas simple que Git.
No hay tantas funciones para aprender , son similares a los otros sistema.
Viene equipado con una interfaz Web independiente y una amplia documentación en la comprensión de mercurial.
Es liviano.
Solo se usa en proyectos grandes.
Es facil de aprender
Es liviano
Es Open Source
Tiene version portable
Tiene el servidor listo y preparado en menos de 5 minutos
Hay una gran diferencia a la hora de usar windows o linux
El que hostea queda permanentemente bloqueado a la hora de trabajar con la consola
Se puede utilizar para adaptarse a cualquier tipo de proyecto.
Es fácil de modificar muy intuitivo.
Integrable se puede añadir proyectos existenetes.
Tiene una comunidad fuerte que mantiene las cosas, como plug-ins y bastantes herramientas de terceros como GUI para añadir interfaces graficas para el sistema.
Se trabaja siempre con acceso al servidor remoto.
No es muy popular.
Consume ancho de banda.
Estadísticamente es lento.
El Launchpad es nuevo.
Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación.
Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones o VCS (del inglés Version Control System). Estos sistemas facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas (por ejemplo, para algún cliente específico). Ejemplos de este tipo de herramientas son entre otros: CVS, Subversion, SourceSafe, ClearCase, Darcs, Bazaar, Plastic SCM, Git, SCCS, Mercurial, Perforce, Fossil SCM, Team Foundation Server.
El control de versiones se realiza principalmente en la industria informática para controlar las distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM (siglas del inglés Source Code Management). Sin embargo, los mismos conceptos son aplicables a otros ámbitos como documentos, imágenes, sitios web, etc.
Un sistema de control de versiones debe proporcionar:
Mecanismo de almacenamiento de los elementos que deba gestionar (ej. archivos de texto, imágenes, documentación...).
Posibilidad de realizar cambios sobre los elementos almacenados (ej. modificaciones parciales, añadir, borrar, renombrar o mover elementos).
Registro histórico de las acciones realizadas con cada elemento o conjunto de elementos (normalmente pudiendo volver o extraer un estado anterior del producto).
Aunque no es estrictamente necesario, suele ser muy útil la generación de informes con los cambios introducidos entre dos versiones, informes de estado, marcado con nombre identificativo de la versión de un conjunto de ficheros, etc.
La terminología empleada puede variar de sistema a sistema, pero a continuación se describen algunos términos de uso común. Repositorio El repositorio es el lugar en el que se almacenan los datos actualizados e históricos de cambios, a menudo en un servidor. A veces se le denomina depósito o depot. Puede ser un sistema de archivos en un disco duro, un banco de datos, etc.. Módulo Conjunto de directorios y/o archivos dentro del repositorio que pertenecen a un proyecto común. Revisión ("version") Una revisión es una versión determinada de la información que se gestiona. Hay sistemas que identifican las revisiones con un contador (Ej. subversion). Hay otros sistemas que identifican las revisiones mediante un código de detección de modificaciones (Ej. Git usa SHA1). A la última versión se le suele identificar de forma especial con el nombre de HEAD. Para marcar una revisión concreta se usan los rótulos o tags. Etiquetar o Rotular ("tag") Darle a alguna versión de cada uno de los ficheros del módulo en desarrollo en un momento preciso un nombre común ("etiqueta" o "rótulo") para asegurarse de reencontrar ese estado de desarrollo posteriormente bajo ese nombre. En la práctica se rotula a todos los archivos en un momento determinado. Para eso el módulo se "congela" durante el rotulado para imponer una versión coherente. Pero bajo ciertas circunstancias puede ser necesario utilizar versiones de algunos ficheros que no coinciden temporalmente con las de los otros ficheros del módulo. Los tags permiten identificar de forma fácil revisiones importantes en el proyecto. Por ejemplo se suelen usar tags para identificar el contenido de las versiones publicadas del proyecto. En algunos sistemas se considera un tag como una rama en la que los ficheros no evolucionan, están congelados. Línea base ("baseline") Una revisión aprobada de un documento o fichero fuente, a partir del cual se pueden realizar cambios subsiguientes. Abrir rama ("branch") o ramificar Un módulo puede ser branched o bifurcado en un instante de tiempo de forma que, desde ese momento en adelante se tienen dos copias (ramas) que evolucionan de forma independiente siguiendo su propia línea de desarrollo. El módulo tiene entonces 2 (o más) "ramas".
