Tema 10 - Sistemas de Control de Versiones de última generación (DCA) I

Tema 10 - Sistemas de Control de Versiones de últimageneración (DCA)

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) II

HISTORIAL DE REVISIONES

NÚMERO FECHA MODIFICACIONES NOMBRE

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) III

Índice

1. ¿Qué es un Sistema de Control de Versiones (SCV)? 1

2. ¿En qué consiste el control de versiones? 1

3. Conceptos generales de los SCV (I) 1

4. Conceptos generales de los SCV (II) 2

5. Tipos de SCV. 2

6. Centralizados vs. Distribuidos en 90sg 2

7. ¿Qué opciones tenemos disponibles? 2

8. ¿Qué podemos hacer con un SCV? 3

9. Tipos de ramas 3

10. Formas de integrar una rama en otra (I) 3

11. Formas de integrar una rama en otra (II) 4

12. SCV’s con los que trabajaremos 4

13. Git (I) 5

14. Git (II) 5

15. Git (III) 5

16. Git (IV) 6

17. Git (V) 6

18. Git (VI) 7

19. Git (VII) 7

20. Git (VIII) 7

21. Git (IX) 8

22. Git (X) 8

23. Git (XI) 9

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) IV

24. Git (XII) 9

25. Git (XIII) 9

26. Git (XIV) 10

27. Git (XV) 10

28. Git (XVI) 11

29. Git (XVII) 11

30. Git. Vídeos relacionados 12

31. Mercurial (I) 12

32. Mercurial (II) 12

33. Mercurial (III) 12

34. Mercurial (IV) 13

35. Mercurial (V) 13

36. Mercurial (VI) 13

37. Mercurial vs. Git 14

38. Mercurial. Vídeos relacionados 14

39. Bazaar (I) . It just works 14

40. Bazaar (II) 14

41. Bazaar (III) 15

42. Bazaar (IV) 15

43. Bazaar (V) 15

44. Bazaar. Vídeos relacionados 16

45. Git vs. Mercurial vs. Bazaar 16

46. Prácticas individuales 16

46.1. Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

46.2. Mercurial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

46.3. Bazaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

46.4. Darcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) V

47. Prácticas en grupo 17

48. Aclaraciones 17

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 1 / 17

Logo DLSI

Tema 10 - Sistemas de Control de Versiones de última generaciónCurso 2019-2020

1. ¿Qué es un Sistema de Control de Versiones (SCV)?

Se trata de un software que nos permite conocer información de las modificaciones que vamos haciendo a nuestro software.

En los scv de hoy en día esta información se aplica como un todo al conjunto de archivos de nuestro producto que hemos idomodificando de alguna manera.

Con estas modificaciones podemos:

• Mantener la ultima versión de los archivos que queramos.

• Volver a alguna versión anterior. . . no necesariamente la última.

• Aislarlas para poder proporcionarlas a otro desarrollador como un parche.

Pero si nos fijamos detenidamente, todo esto puede hacerse manualmente. . .

2. ¿En qué consiste el control de versiones?

¿Qué nos aportan realmente?

La gestión automática de los cambios que se realizan sobre uno o varios ficheros de un proyecto.

Restaurar cada uno de los ficheros de un proyecto a un estado de los anteriores por los que ha ido pasando (no solo alinmediatamente anterior).

Permitir la colaboración de diversos programadores en el desarrollo de un proyecto.

Un histórico de las acciones llevadas a cabo, cúando y por quién. . . cosa muy útil cuando un proyecto es desarrolladopor varias personas de manera simultanea.

3. Conceptos generales de los SCV (I)

RepositorioEs la copia maestra donde se guardan todas las versiones de los archivos de un proyecto.

Copia de trabajoLa copia de los ficheros del proyecto que podemos modificar. Cada desarrollador tiene la suya propia.

Check Out / CloneLa acción empleada para obtener una copia de trabajo desde el repositorio. En los scv distribuídos -como Git- estaoperación se conoce como clonar el repositorio por que, además de la copia de trabajo, proporciona a cada programadorsu copia local del repositorio a partir de la copia maestra del mismo.

Check In / CommitLa acción empleada para llevar los cambios hechos en la copia de trabajo a la copia local del repositorio -CheckIn-. Estocrea una nueva revisión de los archivos modificados. Cada commit debe ir acompañado de un Log Message el cual es uncomentario -Una cadena de texto que explica el commit- que añadimos a una revisión cuando hacemos el commit oportuno.

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 2 / 17

4. Conceptos generales de los SCV (II)

PushLa accion que traslada los contenidos de la copia local del repositorio de un programador a la copia maestra del mismo.

Update/Pull/Fetch+Merge/RebaseAcción empleada para actualizar nuestra copia local del repositorio a partir de la copia maestra del mismo, además deactualizar la copia de trabajo con el contenido actual del repositorio local.

ConflictoSituación que surge cuando dos desarrolladores hacen un commit con cambios en la misma región del mismo fichero. Elscv lo detecta, pero es el programador el que debe corregirlo.

EtiquetarPoner un nombre común a todos los ficheros bajo control de versiones de un proyecto en un instante determinado.

RamaRepresenta una línea de evolución de nuestro software. Podemos tener todas las que queramos, pero normalmente una esespecial: trunk, master, etc. . .

5. Tipos de SCV.

Por la forma de almacenar los contenidos

Centralizados. Hay un único repositorio compartido por todos los desarrolladores. Sólo un responsable o grupo deresponsables pueden llevar a cabo tareas administrativas en este repositorio. Es el caso de CVS y Subversion.Distribuidos: Cada usuario tiene su propio repositorio. Los repositorios de todos los desarrolladores del proyecto puedenintercambiar información entre ellos. Es habitual disponer de un repositorio central que sirve como sincronización entretodos los repositorios de los desarrolladores. Es el caso de git, mercurial, bazaar, monotone, etc. . .

Por la forma de modificar los contenidos de la copia local

Colaborativos: Varios desarrolladores pueden estar modificando el mismo fichero simultáneamente. Puden aparecerconflictos por modificar varios desarrolladores la misma parte del archivo. Es el caso de git o mercurial.Exclusivos: Sólo un desarrollador puede estar modificando un archivo a la vez, el resto sólo pueden leerlo. Una vez sehan pasado los cambios al repositorio entonces ya lo puede modificar otro desarrollador, pero nuevamente sólo uno. Esel caso de RCS o de SourceSafe.

6. Centralizados vs. Distribuidos en 90sg

7. ¿Qué opciones tenemos disponibles?

Hoy en día disponemos de muchos y diversos scv

bazaar que es el sucesor de arch.CVSdarcsgitmercurialmonotonesubversionplasticscm, breve introducción en la wikipediaperforce, breve introducción en la wikipediabitkeeper

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 3 / 17

8. ¿Qué podemos hacer con un SCV?

Operaciones basicas

Crear un repositorioClonar un repositorioActualizar un repositorio local con cambios remotosCrear un commitActualizar un repositorio remoto con cambios localesCrear una rama local y hacerla más tarde remota.Importar cambios de una rama en otra.

9. Tipos de ramas

Ramas de largo recorrido

Por lo general indican distintas versiones estables de nuestro software (v1.0, v2.0, etc. . . )Es el caso de ramas como master o trunk.Algunos proyectos disponen de ramas que complementan a las anteriores: next, proposed, pu (proposed updates).

Ramas puntuales

Son ramas que se crean para trabajar en ellas en un solo aspecto. En inglés se las suele llamar Topic Branches.Puede representar la corrección de un fallo, el añadido de una característica nueva o incluso probar algo de formaexperimental.Algunos desarrolladores emplean un prefijo en su nombre para identificar para qué se crearon:• Tip: Una idea ( tip-speedincrease, tip/memsizereduction, etc. . . )• Wip: Work in Progress ( wip-bugdetection, etc. . . )• Hotfix: Arreglo de un fallo ( hotfix/segfault )• Iss: Un asunto (issue) identificado -fallo, nueva característica, etc. . . - ( iss32, iss32v2, etc..)

10. Formas de integrar una rama en otra (I)

MezclaSupongamos esta situación:master: A--B--C

topic: A--B--C\X--Y--Z v1

El tiempo pasa: A--B--C--D--E--F v2\X--Y--Z

mezcla: A--B--C--D--E--F--M v3\ /+X--Y--Z+

v1 Rama tópicov2 Tres nuevos commits en masterv3 Un nuevo commit M representa la mezcla

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 4 / 17

11. Formas de integrar una rama en otra (II)

Rebasamiento

No todos los scv disponen de esta posibilidad.

Aplicado al ejemplo anterior. . . obtendríamos esta nueva situación:

master: A--B--C

topic: A--B--C\X--Y--Z v1

El tiempo pasa: A--B--C--D--E--F v2\X--Y--Z

mezcla: A--B--C--D--E--F v3\X'--Y'--Z'

v1 Misma rama tópicov2 Mismos tres nuevos commits en masterv3 La rama tópico se trasplanta de su antiguo commit origen (C) al nuevo (F).

Lo que produce una historia más lineal:

A--B--C--D--E--F--X'--Y'--Z'

Echa un vistazo a este vídeo que explica de forma sencilla la diferencia entre rebase y merge:

12. SCV’s con los que trabajaremos

Nos vamos a centrar en tres de ellos. Todos serán distribuídos, ya que con uno distribuído podemos simular el uso de unocentralizado.

Veremos una breve introducción a cada uno. . . incluso alguna característica especial que posean.

Veremos como llevan a cabo las operaciones básicas que hemos descrito anteriormente.

Los tres scv’s que emplearemos son:

1. git

2. bazaar

3. mercurial

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 5 / 17

13. Git (I)

Los desarrolladores del núcleo linux emplean BitKeeper hasta 2005.

BitKeeper es un scv distribuído. Git también lo es, al igual que Darcs, Mercurial o Bazaar y Monotone.

Linus comienza el desarrollo de git el 3 de abril de 2005, lo anuncia el dia 6 de abril.

Git se auto-hospeda el 7 de abril de 2005.

Consta de herramientas de bajo de nivel (plumbing) y de alto nivel (porcelain). Estas últimas son las que se emplean habitual-mente e internamente llaman a las de bajo nivel.

Cada nuevo commit creado en git es una foto de nuestro proyecto en ese instante. . . identificada por un número. . . su claveSHA-1.

El algoritmo SHA-1 ya no es considerado seguro y Git ya está implementando el soporte de SHA-256.

14. Git (II)

Toda la metainformación de git se guarda en un directorio que reside en la carpeta raíz de nuestro proyecto y que se llama .git:

.git|-- branches|-- COMMIT_EDITMSG|-- config|-- description|-- FETCH_HEAD|-- gitk.cache|-- HEAD|-- hooks|-- index|-- info|-- logs|-- objects|-- ORIG_HEAD+-- refs

15. Git (III)

Uso

Al igual que ocurre con todas las herramientas de este tipo, existe una órden (git) que admite diferentes subórdenes.

El primer uso que podemos hacer de ella es para saber la versión de git que tenemos instalada.

git --version

O para iniciar el repositorio local de un proyecto:

git init proyecto

funcionamiento habitual. . .

git add .git statusgit commit -m "Primer commit." -m "Descripcion detallada."git commit -a

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 6 / 17

16. Git (IV)

Configuración local

Se lleva a cabo en un archivo local al proyecto. Se trata de un archivo de texto.

Por tanto cada proyecto puede tener su configuración local

.git/config

Configuración global

Se lleva a cabo en un archivo particular para cada usuario del s.o. Se trata de un archivo de texto con el mismo formatoque en el caso anterior.

Por tanto cada usuario puede tener su configuración global para todos sus proyectos

~/.gitconfig

Ejemplos de configuración

git config user.name "nombre apellidos"git config user.email "usuario@email.com"...git config --global user.name "nombre apellidos"git config --global user.email "usuario@email.com"

17. Git (V)

Ramas

Es una de las características más valoradas en git. La facilidad para el trabajo con ramas.

Además es barato trabajar con ramas. . . a diferencia de otros scv

git branch [-a] [-r]git show-branch...git checkout [-b] [rama-de-partida]git log [-p]

Estado

git statusgit log...git showgit diff

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 7 / 17

18. Git (VI)

Descartar cambios

git reset --hardgit checkout ruta-archivos o rama

Repositorios remotos

git remote add nombre protocologit remote add origin maquina:ruta/hasta/repo...[ssh] [http] [git] [git+ssh]git clone maquina:ruta/hasta/repo

Operaciones con repositorios remotos

git pull [origin] [rama]git push [repo] [rama]git checkout -b rama origin/rama-remotagit fetchgit mergegit pull = git fetch + git mergegit rebase otra-rama

19. Git (VII)

Stash

Imagina. . . estás modificando tu copia de trabajo. . . montones de archivos modificados (sin hacer un commit aún) desdeel último pull.

En ese preciso instante, tu compañero -al que tanto aprecias- te dice que la actualices desde el repositorio originalporque acaba de subir unos cambios. . . importantisimos. . . Ah!. . . y HAZLO YA!!

Ok. . . lo que tu digas:

git stashgit pullgit stash pop

20. Git (VIII)

Bisect

¿Bi-qué?. . . búsqueda B-I-N-A-R-I-A entre los commits.

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 8 / 17

git bisect startgit bisect bad # la version actual esta malgit bisect good commit/tag # una version que sabemos que funciona

Después de ir alternando entre commits buenos y malos estaremos parados en el último commit entre los dos originalesque introdujo el cambio erróneo. Para volver al estado original del que hemos partido:

git bisect reset

. . . There’s one more thing!

git bisect run mi-guion argumentos

"mi-guion" es un guión de shell que devuelve 0, 1..124, 126, 127

21. Git (IX)

Cherry-Picking

Al hacer un merge o un rebase. . . aplicamos varios commits simultáneamente. . .¿Y si queremos solo uno?..

git cherry-pick 7a2ed53git cherry-pick master

Shortlog

Resume la salida de git log en un formato apropiado para anuncios de nuevas versiones. . .Pero también es apropiado para extraer información sobre el trabajo de los desarrolladores. Prueba esto:

git shortlog -s -n --all --no-merges

22. Git (X)

Aliases

Podemos crear alias para órdenes+opciones que usemos habitualmente. . .

git config --global alias.co checkoutgit config --global alias.ci commitgit config --global alias.st statusgit config --global alias.br branchgit config --global alias.hist 'log --pretty=format:"%h %ad | %s%d [%an]" -- ←↩

graph --date=short'git config --global alias.type 'cat-file -t'git config --global alias.dump 'cat-file -p'

Y lo que esto hace realmente es añadir a ~./gitconfig estas líneas:

[alias]co = checkoutci = commitst = statusbr = branchhist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 9 / 17

23. Git (XI)

sugerenciaSi tu shell lo permite. . . aún puedes abreviar más. . . , ten en cuenta que esto no específico de git.

# ~/.profile , ~/.bashrc# Consulta la documentacion de tu shell.

alias gs='git status 'alias ga='git add 'alias gb='git branch 'alias gc='git commit'alias gd='git diff'alias go='git checkout 'alias gk='gitk --all&'alias gx='gitx --all'

alias got='git 'alias get='git '

Un ejemplogo <branch>

24. Git (XII)

Detached HEAD

No solo podemos cambiar de rama. . . sino volver a un punto concreto en el pasado.

Esto produce una rama-virtual cuya cabeza es el numero-hash que hemos indicado:

$ git checkout 415e7c2Note: checking out '415e7c2'.

You are in 'detached HEAD' state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you maydo so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 415e7c2... First Commit$ cat message.txtHello, World

25. Git (XIII)

Etiquetas / Tags

Los número que genera SHA1 para cada commit, no proporcionan mucha información a las personas.

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 10 / 17

Nos puede interesar más asociar un texto significativo a un hash, algo que represente una información para nosotros,p.e.: v1.0.

Eso se hace con la orden tag de git.

git tag v1.0

Si no indicamos nada. . . etiquetamos el último commit de la rama actual.

A partir de este momento podemos emplear esa etiqueta en lugar del hash asociado al commit que la tiene, p.e:

git checkout v1.0...git checkout v1.0~3

La órden git tag sin parámetros lista las etiquetas que tenemos puestas.

26. Git (XIV)

Bare repos

Es el término que se emplea en git para referirse al repositorio local de un proyecto. . . al directorio .git.

No tienen copia de trabajo, sólo metadatos.

Algunas opciones (como clone) permiten trabajar con ellos:

$ git clone --bare hello hello.gitCloning into bare repository hello.git...done.$ ls hello.gitHEADconfigdescriptionhooksinfoobjectspacked-refsrefs

Habitualmente -y para identificarlos fácilmente- estos repositorios se suelen llamar como el proyecto que representan y con laextensión .git, p.e.: hola-mundo.git.

27. Git (XV)

Hooks

Los hooks son guiones que se ejecutan automáticamente antes o después de determinadas acciones como commit,push, etc. . .

Por ejemplo, en el hook pre-commit podríamos comprobar si el mensaje tiene errores ortográficos.

Cada vez que creamos un repositorio git, disponemos del directorio .git/hooks donde ya hay ejemplos de estosguiones:

applypatch-msg.sample post-update.sample pre-commit.samplepre-push.sample update.sample commit-msg.samplepre-applypatch.sample prepare-commit-msg.sample pre-rebase.sample

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 11 / 17

Puedes tomar cualquiera de ellos como punto de partida, eso sí:

1. Quítales el sufijo .sample2. Dales permiso de ejecución si no lo tienen

Para tener más información de cada uno de ellos ejecuta:

git help hooks

28. Git (XVI)

Reflog

Es la manera en la cual git guarda información de cuándo se actualizan las "cabezas" de las ramas.

git refloggit reflog show

Para referirse a los commits emplea la notación:

rama@{referencia}

master@{5} v1tip/speedincrease@{17} v2bugfix/badcss@{one.month.ago} v3v1 Dónde apuntaba master hace 5 movimientos.v2 Dónde apuntaba tip/speedincrease hace 17 movimientos.v3 Dónde apuntaba bugfix/badcss hace un mes.

Se puede usar, por ejemplo, para recuperar commits perdidos.

Clean

Elimina de la copia de trabajo los archivos que no están bajo control de versiones. ¡Lleva cuidado al usarla!

git clean

Fsck

Dado que git se puede ver como un sistema de ficheros indexado por contenido. . . también tiene su herramienta fsck ochkdsk correspondiente:

git fsck

29. Git (XVII)

Herramientas gráficas

gitkgit guigit viewgitggigglegourcetigY aquí tienes más.

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 12 / 17

30. Git. Vídeos relacionados

31. Mercurial (I)

web del proyecto.

Su nombre le viene del término hidrargirio

Es un scv distribuído. Es software libre. Disponible en OS-X, Windows y GNU/Linux.

Surge aproximadamente a la vez que git, las órdenes que entiende se llaman prácticamente de la misma forma. Escrito enpython y partes en C.

Dado que funciona de manera similar a git los flujos de trabajo que tenemos disponibles son similares a los que ya conocemosde git.

Toda la información relativa al control de versiones de un proyecto se guarda en el directorio raíz del proyecto, concretamenteen el subdirectorio ".hg".

La configuración general para cada usuario se guarda en ~./hgrc y la configuración local para cada proyecto se guarda en<repo>/.hg/hgrc.

32. Mercurial (II)

Ejemplo 1

1 hg clone http://github.com/repo/hola-mundo2 cd hola-mundo3 (editar ficheros)4 hg add (nuevos ficheros)5 hg commit -m 'Cambios'6 hg push

Ejemplo 2

1 hg init (directorio del proyecto)2 cd (directorio del proyecto)3 (Anyadimos archivos..)4 hg add5 hg commit -m "Primer commit"

33. Mercurial (III)

Admite el añadido de extensiones

Podemos ver las extensiones disponibles con:

hg help extensions

Pedir información de una de ellas con:

hg help nombre-extension

Las extensiones se deben habilitar, p.e. en .hg/hgrc:

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 13 / 17

[extensions]foo =# Podemos especificar la ruta concreta[extensions]myfeature = ~/.hgext/myfeature.py

34. Mercurial (IV)

También se pueden deshabilitar de una en una:

[extensions]# disabling extension bar residing in /path/to/extension/bar.pybar = !/path/to/extension/bar.py# ditto, but no path was supplied for extension bazbaz = !

En la instalación de mercurial vienen estas extensiones por defecto, pero también disponemos de otras hechas por terceros.Por cierto. . . ¿a qué te suena la extensión shelve?

35. Mercurial (V)

Para dar de alta un nuevo repositorio en un proyecto, edita su <proyecto>/.hg/hgrc y añade una nueva entrada enpaths así:

[paths]default = http://www.hgrepos.net/r1 v1default-push = ssh://dca@hgrepos.net/r1 v2...alias1 = URL1alias2 = URL2

v1 Es especial, se usa como valor por defecto cuando no especificamos la URL.v2 Idem pero cuando hacemos un push.

Los conflictos se marcan igual que en otros scv:

<<<<<<< /tmp/conflict/crab.cppvoid function() {=======int function() {>>>>>>> /tmp/crab.cpp

36. Mercurial (VI)

Si usas subversion, quizás te sean útiles hgsubversion y también estos guiones.

Estas otras aplicaciones también pueden serte útiles al emplear mercurial:

1. hgview, tiene una variante en modo texto llamada hgview-curses (algo menos completa).2. tortoisehg

Dispones también del libro de mercurial y de una guía.

Si usas Eclipse te puede interesar este plugin. Otros editores/IDEs también disponen de plugins para trabajar con mercurial.

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 14 / 17

37. Mercurial vs. Git

De los creadores de Git is MacGyver and Mercurial is James Bond

. . . presentamos: Git is Wesley Snipes, Mercurial is Denzel Washington and Subversion is . . .

Git vs. Mercurial

En Git los objetos con los que trabaja son: blob, tree y commit.

Mercurial usa los mismos conceptos pero los llama: file, manifest y changeset.

Ambos scv’s usan una clave SHA-1 para identificar estos tres tipos de objetos. Mercurial llama a esta clave nodeid.

Ambos ven la historia del proyecto como un Grafo Acíclico Dirigido.

Mercurial distingue entre dos tipos de ramas: ramas con nombre y clones de repositorios.

Mercurial además de la clave SHA-1 asociada a un changeset genera un número de revision local.

Mercurial no necesita añadir los cambios de los archivos al índice (stage) como git.

38. Mercurial. Vídeos relacionados

39. Bazaar (I) . It just works

web del proyecto.

En ocasiones se le llama Bazaar-NG (New Generation) ya que es una reimplementación de GNU Arch

El nombre le viene de un ensayo publicado por Eric S. Raimond: The Cathedral and the Bazaar: Musings on Linux and OpenSource by an Accidental Revolutionary.

En la propia web del proyecto se nos dan 10 razones para usar bazaar.

Como mercurial, se puede ampliar su funcionalidad con plugin’s.

Toda la información relativa al control de versiones de un proyecto se guarda en el directorio raíz del proyecto, concretamenteen el subdirectorio ".bzr".

40. Bazaar (II)

Funcionamiento

Creamos e iniciamos un repositorio:

bzr init repo-bzr

Trabajamos en él:

cd repo-bzredit file1 file2 ...bzr add file1 file2 ...bzr statusbzr ignore *~bzr alias commit="commit --strict"

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 15 / 17

41. Bazaar (III)

Creamos un commit y vemos el log:

bzr commit -m "Anyadido hola.txt" hola.txtbzr log

bzr log------------------------------------------------------------revno: 1committer: Fernando Perez <fperez@ua.es>branch nick: repo-bzrtimestamp: Mon 2013-12-16 20:59:22 +0100message:

Anyadido hola

Probamos a actualizar nuestra copia de trabajo

bzr update

42. Bazaar (IV)

Las ramas viven en su propio directorio.

bzr branch . rama2bzr branch rama2 displaycd rama2; edit hola.txtbzr commit -m "decimos adios"Committing to: /home/fernando/repos/repo-bzr/rama2/modificado hola.txtCommitted revision 2.

cd ../displaybzr merge ../rama2

M hola.txtTodos los cambios se aplicaron correctamente.

bzr statusmodified:

hola.txtpending merge tips: (use -v to see all merge revisions)

Fernando Perez 2013-12-16 decimos adios

43. Bazaar (V)

Algunas características especiales

Hosting recomendado: https://launchpad.net/ o también http://savannah.gnu.org/

Cliente con interfaz gráfica de usuario: bazaar explorer

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 16 / 17

Unity3D es un motor de juegos en 3D que permite configurar bazaar como herramienta de control de versiones para susproyectos.

Configuración

En el directorio $HOME/.bazaar, en tres archivos:

• bazaar.conf• locations.conf• authentication.conf

Obtenemos información de la configuración con:

bzr config

Modificamos la configuración con:

bzr config opt=valuebzr config --remove opt

44. Bazaar. Vídeos relacionados

45. Git vs. Mercurial vs. Bazaar

A lo largo del tema no hemos tratado de presentar un ganador, tan sólo ver tres implementaciones diferentes de una mismatecnología: sistemas de control de versiones distribuídos

Al terminar este tema sí que deberíais tener una serie de criterios para ayudaros a decidir qué scv deberías emplear.

Si aún así no fuera suficiente, quizás esta web y esta otra puedan ayudarte un poco más.

46. Prácticas individuales

46.1. Git

Crea (si no tienes ya) una cuenta en github, gitlab o bitbucket. Una vez hecho da de alta un proyecto/repositorio y configuragit localmente para que puedas hacer push/pull a él.

Créate algunos alias locales y globales en git.

Provoca un fallo en el software en un commit de manera que después de crear varios commits más puedas encontrarlo congit bisect.

Haz uso de algún hook de git.

A título personal y no para la práctica, trata de migrar un repositorio svn a git. Repasa la órden svn de git. Echa un vistazo ala documentación. Aquí tienes ejemplos de repositorios subversion.

46.2. Mercurial

Crea o clona un proyecto con mercurial. Aquí tienes servicios de almacenamiento de repositorios Mercurial.

Genera cambios y crea los commits correspondientes.

Crea ramas y comparte commits entre ellas (merge).

Mercurial también dispone de la orden bisect. Úsala en algún ejemplo.

hg bisect --help

Tema 10 - Sistemas de Control de Versiones de última generación (DCA) 17 / 17

46.3. Bazaar

Bazaar no dispone directamente de la orden bisect, pero se puede instalar mediante un plugin. Úsala en algún ejemplo.

Crea un repositorio, dótalo de contenido, haz modificaciones, genera commits, crea ramas, etc. . .

Clona algún repositorio de launchpad. Modifica archivos y/o añade nuevos. Genera los commits locales correspondientes.

Crea y prueba algunos alias, echa un vistazo a http://doc.bazaar.canonical.com/bzr-0.11/using_aliases.htm. También puedesobtener ayuda con:

bzr alias --help

46.4. Darcs

Trata de crear un repositorio con darcs. Una vez hecho, úsalo para guardar cambios en tu proyecto.

ENTREGA:

La práctica se entregará en pracdlsi en las fechas allí indicadas.

47. Prácticas en grupo

Explicadnos qué es SVK.

Explicadnos qué es Tailor.

Explicadnos qué son los submódulos en git. Presentadnos algún ejemplo de uso.

Explicadnos qué es git-annex. Poned algún ejemplo de uso.

Bazaar dispone de bound branches. . . tratad de explicarnos qué son.

ENTREGA:

La práctica o prácticas se entregará/n en (y sólo en) pracdlsi en las fechas y condiciones allí indicadas.

48. Aclaraciones

EN NINGÚN CASO ESTAS TRANSPARENCIAS SON LA BIBLIOGRAFÍA DE LA ASIGNATURA.

Debes estudiar, aclarar y ampliar los conceptos que en ellas encuentres empleando los enlaces web y bibliografía recomendadaque puedes consultar en la página web de la ficha de la asignatura y en la web propia de la asignatura.