Revisión de 14:28 12 abr 2018 (ver código fuente)
Lluis.fita  (Discusión | contribuciones)
 (Empezando `repositorios')
 
Revisión de 12:24 5 jun 2019 (ver código fuente)
Lluis.fita  (Discusión | contribuciones) 
 (Creación página)
Edición siguiente →
Los repositorios son una herramienta que facilita el desarrollo y el repartimento de codigo entre múltiples usuari.x.s
= Control de versions =
El control de versiones es una herramienta de gestión de ficheros de texto (normalmente códigos de programación) centralizados en un '''repositorio''' que permite tener controlado la evolución de los mismos y el compartimiento entre distintes desarroladores.
Básicamante consiste en el almacenaje de los ficheros en un servidor. La aplicación se encarga de mantener un registro de las distintas modificaciones hechas en los ficheros llamadas '''versiones''', y permite además la interacción y consulta entre ellas. Al mismo tiempo facilita la creación de evolución paralelas de los ficheros llamadas '''ramas''' y la detección automática de conflictos entre modificaciones simultáneas. Así mismo, permite muy claramente la actualización de multiples copias en muchas computadoras distintas.
== Funcionamento ==
# Un usuarie '''A''' se descarga los ficheros de un servidor.
# Realiza las modificaciones en su máquina `local'
# Sube ('''commit'''), del Inglés la nueva versión 1 de los ficheros cambiados en el servidor
[[Archivo:usuarieA.png|frame|50px|Creación de la versión 1 por el Usuarie A]
# Otro usuarie '''B''', cuando se descargue los ficheros ya obtendrá la versión de los ficheros con las modificaciones del usuarie '''A'''
# Este usuarie '''B''' realiza su trabajo y actualiza una serie de ficheros
# Cuando termina, sube la nueva versión 2 de los ficheros modificados.
[[Archivo:usuarieB.png|frame|50px|Creación de la versión 2 por el Usuarie B]
# Si en paralelo un usuarie '''C''' modificó algún fichero de la versión 2 que también modificó el usarie '''B''', el control de versiones lo detecterá cuando se haga el commit y alertará al usuarie '''C''' y paralizará la subida hasta que no se resuelva el '''conflicto'''
[[Archivo:usuarieC.png|frame|50px|Conflicto de creación de la versión 3 por el Usuarie C debido a los cambios introducidos en la versión 2 por el Usuarie B]
En este ejemplo, se deberá decidir qué cambios se suben al servidor para la creación de la versión 3. Esta decisión tenrá que ser coordinada entre todes les usuaries
Cuando se realiza un commit, este siempre va acompañado por un comentario del usuarie para que sea fácil de entender y reconocer los cambios realizados
== Ramas ==
Todo sistema de control de versiones tiene una rama principal o '''trunk'''. Esta evolución del código suele corresponder con la versión 'oficial'. Siendo la versión operativa o que funciona de los ficheros. 
El manejo de ramas de un repositorio permite la evolución independiente de los ficheros o código sin interferir con la rama principal. Básicamente consiste en una copia de una determinada versión del repositorio que requiere aislarse de la evolución del conjunto de usuaries y que no puede interferir con su trabajo por diversos motivos (ej.: tests específicos, evolución compleja, pruebas de resultado dudoso...). Las subidas de las distintas modificaciones de la rama, se vuelven '''versiones''' de la rama.
Al final, las modificaciones de dicha rama pueden ser incorporados en la rama principal y desparacer, o seguir evolucionando independientemente. Antes de subir (commit) los cambios de una rama, es necesario:
# Unir ('''merge''') los ficheros de la rama a la última versión del repositorio ('''merge''' de la rama con el 'trunk')
# Resolver los conflictos que puedan surgir
# Subir la versión unida
[[Archivo:Branches.png|frame|50px|Creación de una rama y posterior inclusión en el 'trunk']
== Generalidades ==
El uso de herramientas de control de versiones presenta una larga serie de ventajas:
* Recuperación rápida y clara de versiones anteriores
* Control y seguimiento de cambios introducidos
* Actualización rápida y sincronizada en múltiples ubicaciones
* Trabajo independiente y coordinado entre varie usuaries
* Copia de seguridad actualizada de ficheros
La herramienta de control de versiones sólo guarda las modificaciones respecto la versión inicial, reduciendo el espacio en disco
Diferentes opciones: [[https://www.nongnu.org/cvs/ cvs]], [[https://subversion.apache.org/ svn]], [[https://git-scm.com/ git]], [[https://www.mercurial-scm.org/ mercurial]]
=== SVN Ejemplo ===
# Descargando la copia del trunk (sin indicar se baja la última versión)
<PRE>
$ svn co [NombreRepositorio] [DirectorioTrabajo]
</PRE>
# Descargando la versión 345 del trunk (sin indicar se baja la última versión)
<PRE>
$ svn co -r 345 [NombreRepositorio] [DirectorioTrabajo]
</PRE>
# Conocer la versión de la copia local (dentro de <CODE>[DirectorioTrabajo]</CODE>)
<PRE>
$ svn info 
</PRE>
# Conocer el estado de la copia local (dentro de <CODE>[DirectorioTrabajo]</CODE>) respecto a la del repositorio ('?': fichero inexistente en el repositorio, 'M': fichero modificado, 'A': añadido, 'D': eliminado, 'C': conflicto, ...)
<PRE>
$ svn stat
?           Fichero1
?           Fichero1a
?           Fichero13
M           Fichero3
M           Fichero4
</PRE>
# Añadir un fichero al repositorio
<PRE>
$ svn add Fichero45
</PRE>
# Conocer las diferencias respecto a la versión actual en el repositorio (r345) ['-', copia repositorio, '+' copia local]
<PRE>
$ svn diff Fichero12a
Index: Fichero12a
--- Fichero12a (revision 345)
+++ Fichero12a (working copy)
@@ -98,6 +98,6 @@
-  DO i=1, 23
+  DO i=1, 35
</PRE>
# Actualizar la copia local
<PRE>
$ svn update
</PRE>
# Subir la modificación
<PRE>
$ svn commit -m "Explicación de la modificación"
</PRE>
== Recomendaciones ==
* Siempre, actualizar antes de subir una modificación
* Realizar todos los tests posibles antes de realizar un 'commit'
* Ser excelso en los comentarios al hacer los 'commits'
* Trabajar en ramas en caso de realizar grandes mofificaciones