Diferència entre revisions de la pàgina «Treballant amb Bazaar»
(Es crea la pàgina amb « Antes de nada, registraros en http://launchpad.net y http://launchpad.net/~hdlorean después; si no hay cosas que no os dejará hacer… También necesitáis insta...».) |
|||
| Línia 1: | Línia 1: | ||
| − | Antes de nada, registraros en http://launchpad.net y http://launchpad.net/~hdlorean después; si no hay cosas que no os dejará hacer… | + | Antes de nada, registraros en http://launchpad.net y http://launchpad.net/~hdlorean después; si no hay cosas que no os dejará hacer… |
| − | También necesitáis instalar bazaar. Con ubuntu: apt-get install bzr. Cuidado!; no es "bazaar" sino "bzr"; bzr es un fork también conocido como bazaar-ng del bazaar original, que a su vez es un fork de gnu arch. | + | También necesitáis instalar bazaar. Con ubuntu: apt-get install bzr. Cuidado!; no es "bazaar" sino "bzr"; bzr es un fork también conocido como bazaar-ng del bazaar original, que a su vez es un fork de gnu arch. |
| − | También podéis probar el GUI. | + | También podéis probar el GUI. |
| − | Unos conceptos básicos: TODO | + | Unos conceptos básicos: TODO |
| − | <br>Configuración inicial | + | <br>Configuración inicial |
| − | bzr whoami "Pedro Páramo <email@example.com>"<br>Así los commits tienen nombre. | + | bzr whoami "Pedro Páramo <email@example.com>"<br>Así los commits tienen nombre. |
| − | Usar un repositorio LOCAL | + | Usar un repositorio LOCAL |
| − | Hacer tu propio branch, ver propuesta modelo desarrollo. Vale para cualquier cosa que queráis tener. No es obligatorio. | + | Hacer tu propio branch, ver propuesta modelo desarrollo. Vale para cualquier cosa que queráis tener. No es obligatorio. |
| − | 1. Os metéis en el directorio que queráis tener versionado. | + | 1. Os metéis en el directorio que queráis tener versionado. |
| − | 2. Arrancar el repositorio (internamente: crea una carpeta oculta dentro). | + | 2. Arrancar el repositorio (internamente: crea una carpeta oculta dentro). |
| − | bzr init<br>3. Añadir todo lo que encuentra en "." . | + | bzr init<br>3. Añadir todo lo que encuentra en "." . |
| − | bzr add . | + | bzr add . |
| − | Alternativamente: meter uno a uno, o con patrones (*.cpp *.h etc).<br>POR FAVOR: No metáis temporales. Ver Ignorar archivos.<br>4. Ver qué estás haciendo, qué hay añadido / cambiado / etc. | + | Alternativamente: meter uno a uno, o con patrones (*.cpp *.h etc).<br>POR FAVOR: No metáis temporales. Ver Ignorar archivos.<br>4. Ver qué estás haciendo, qué hay añadido / cambiado / etc. |
| − | bzr status<br>5. ¡APLICAR CAMBIOS!: Añadir esta versión al repo. | + | bzr status<br>5. ¡APLICAR CAMBIOS!: Añadir esta versión al repo. |
| − | bzr commit -m "mensaje" | + | bzr commit -m "mensaje" |
| − | Si no pones el mensaje te abre un editor. La primera línea debe ser descriptiva; el resto es en detalle.<br>Congratz!!! El código ya está bajo versiones. Podéis ver Comandos útiles ahora para saber qué más se puede hacer. | + | Si no pones el mensaje te abre un editor. La primera línea debe ser descriptiva; el resto es en detalle.<br>Congratz!!! El código ya está bajo versiones. Podéis ver Comandos útiles ahora para saber qué más se puede hacer. |
| − | Subir tu código a launchpad | + | Subir tu código a launchpad |
| − | Para copia de seguridad, tener varios equipos, etc. | + | Para copia de seguridad, tener varios equipos, etc. |
| − | bzr push bzr+ssh://<me>@bazaar.launchpad.net/~<me>/hdlorean/mine | + | bzr push bzr+ssh://<me>@bazaar.launchpad.net/~<me>/hdlorean/mine |
| − | Sube como tu usuario (<me>@…) al espacio tuyo (~<me>) una rama del proyecto. No estoy seguro si mine puede cambiarse por "mi nombre de branch". de hecho mine *es* el nombre de branch que le quiera dar yo.<br>TODO sincronizar portátil / sobremesa | + | Sube como tu usuario (<me>@…) al espacio tuyo (~<me>) una rama del proyecto. No estoy seguro si mine puede cambiarse por "mi nombre de branch". de hecho mine *es* el nombre de branch que le quiera dar yo.<br>TODO sincronizar portátil / sobremesa |
| − | Se parece a mezclar branches con tu grupo de trabajo: Primero lo subes a internete con bzr push, luego lo mezclas cambios de uno y otro con bzr merge, o alternativamente te bajas directamente en el que no tiene los nuevos con bzr pull. | + | Se parece a mezclar branches con tu grupo de trabajo: Primero lo subes a internete con bzr push, luego lo mezclas cambios de uno y otro con bzr merge, o alternativamente te bajas directamente en el que no tiene los nuevos con bzr pull. |
| − | Trabajar contra un repositorio compartido | + | Trabajar contra un repositorio compartido |
| − | Ver propuesta modelo desarrollo. Hay dos posibilidades, según tengas un "branch" o un "checkout". Con el primero haces commits locales sin internet; con el segundo no. | + | Ver propuesta modelo desarrollo. Hay dos posibilidades, según tengas un "branch" o un "checkout". Con el primero haces commits locales sin internet; con el segundo no. |
| − | De fácil a difícil: | + | De fácil a difícil: |
| − | Con checkout (como svn) | + | Con checkout (como svn) |
| − | Descargar | + | Descargar |
| − | bzr checkout http://launchpad.net/~nombre-equipo/hdlorean/nombre-branch carpeta-destino<br>Modificar. | + | bzr checkout http://launchpad.net/~nombre-equipo/hdlorean/nombre-branch carpeta-destino<br>Modificar. |
| − | A partir de aquí, todo es igual que para un local repositorio local (bzr add, bzr commit, etc). Pero para hacer commit necesitas estar conectado a internet y te pedirá user / password. | + | A partir de aquí, todo es igual que para un local repositorio local (bzr add, bzr commit, etc). Pero para hacer commit necesitas estar conectado a internet y te pedirá user / password. |
| − | Si al hacer commit alguien ha tocado en el repositorio ya, te obligará a bajarte los últimos cambios con update (y si hay conflictos te obliga a resolverlos) antes de subirlos. | + | Si al hacer commit alguien ha tocado en el repositorio ya, te obligará a bajarte los últimos cambios con update (y si hay conflictos te obliga a resolverlos) antes de subirlos. |
| − | CUIDADO! Si el checkout es del http, no debería dejarte subir nada salvo con bzr+ssh que va autenticado!!! Y no hemos especificado a dónde subirlo… | + | CUIDADO! Si el checkout es del http, no debería dejarte subir nada salvo con bzr+ssh que va autenticado!!! Y no hemos especificado a dónde subirlo… |
| − | Invito a todo alma indómita que se meta a probar que esto funciona, y explicarme exactamente cómo. YO NO HE PROBADO ESTE MÉTODO AÚN!!! | + | Invito a todo alma indómita que se meta a probar que esto funciona, y explicarme exactamente cómo. YO NO HE PROBADO ESTE MÉTODO AÚN!!! |
| − | Con branch | + | Con branch |
| − | Lo que aquí cuento es aplicable a mezclar tu branch con el del equipo, y gestionar conflictos.<br>Hay dos formas de hacerlo: una, mezclar directamente sobre tu trabajo (parecido a svn update). La otra es bajarte el código del equipo en un branch y hacer un branch "de trabajo" de ese branch, para luego mezclarlos. | + | Lo que aquí cuento es aplicable a mezclar tu branch con el del equipo, y gestionar conflictos.<br>Hay dos formas de hacerlo: una, mezclar directamente sobre tu trabajo (parecido a svn update). La otra es bajarte el código del equipo en un branch y hacer un branch "de trabajo" de ese branch, para luego mezclarlos. |
| − | Descargar | + | Descargar |
| − | bzr branch http://launchpad.net/nombre-equipo/hdlorean/branch-concreto | + | bzr branch http://launchpad.net/nombre-equipo/hdlorean/branch-concreto |
| − | Lo de carpeta destino funciona por defecto. Alternativamente con bzr+ssh (más eficiente).<br>Desde este momento tienes un branch local que va asociado a dónde te lo has bajado.<br>Modificar | + | Lo de carpeta destino funciona por defecto. Alternativamente con bzr+ssh (más eficiente).<br>Desde este momento tienes un branch local que va asociado a dónde te lo has bajado.<br>Modificar |
| − | Igual que en local. Importante terminar con el commit, si no no has hecho nada!! | + | Igual que en local. Importante terminar con el commit, si no no has hecho nada!! |
| − | Bajarse cambios | + | Bajarse cambios |
| − | bzr pull | + | bzr pull |
| − | Solo funciona si no hay cambios locales (cuidado, esto no es svn update, el merge no es automático). Por ejemplo, si al acabar de currar has subido con push, el siguiente paso puede ser un pull.<br>Mezclar branches (se hace en LOCAL siempre) | + | Solo funciona si no hay cambios locales (cuidado, esto no es svn update, el merge no es automático). Por ejemplo, si al acabar de currar has subido con push, el siguiente paso puede ser un pull.<br>Mezclar branches (se hace en LOCAL siempre) |
| − | Pasar cambios de un branch a otro que tienes en el disco duro. Si un branch va en internet creo que se baja los últimos cambios, intenta mezclar con los tuyos y solo te avisa en los conflictos él solito. | + | Pasar cambios de un branch a otro que tienes en el disco duro. Si un branch va en internet creo que se baja los últimos cambios, intenta mezclar con los tuyos y solo te avisa en los conflictos él solito. |
| − | bzr merge ruta-al-destino <br>bzr commit -m "mezclados branch sobre el que trabajaba en local y branch destino"<br>Atención al merge: ruta-al-destino es de dónde quieres coger los cambios. Por ejemplo: | + | bzr merge ruta-al-destino <br>bzr commit -m "mezclados branch sobre el que trabajaba en local y branch destino"<br>Atención al merge: ruta-al-destino es de dónde quieres coger los cambios. Por ejemplo: |
| − | Si tú tienes un origen (digamos un checkout de lo del equipo) y haces un branch para trabajar tú, el merge tendrías que hacerlo en el origen y contra el branch (cd origen; bzr merge ../branch-del-origen); al menos a mí me está funcionando así.<br>Si, sin embargo, estás trabajando contra el branch del equipo, los cambios los cogerías de ahí y por tanto tu ruta al destino sería bzr+ssh://<me>@bazaar.launchpad.net/~nombre-equipo/hdlorean/branch-concreto<br>Es el comando delicado así que hay que tener un poco de ojo hasta que nos aclaremos; recomiendo tener una copia de con lo que se trastee antes por si acaso… | + | Si tú tienes un origen (digamos un checkout de lo del equipo) y haces un branch para trabajar tú, el merge tendrías que hacerlo en el origen y contra el branch (cd origen; bzr merge ../branch-del-origen); al menos a mí me está funcionando así.<br>Si, sin embargo, estás trabajando contra el branch del equipo, los cambios los cogerías de ahí y por tanto tu ruta al destino sería bzr+ssh://<me>@bazaar.launchpad.net/~nombre-equipo/hdlorean/branch-concreto<br>Es el comando delicado así que hay que tener un poco de ojo hasta que nos aclaremos; recomiendo tener una copia de con lo que se trastee antes por si acaso… |
| − | Ejemplo práctico | + | Ejemplo práctico |
| − | Yo estoy trabajando con un compañero en una asignatura, y tengo un servidor en bzr+ssh://direccion/repo/asignatura . Desafortunadamente mi compañero usa eclipse 3.2 y yo tengo instalado ya el 3.3, así que si ponemos todo el workspace bajo control de versiones nos pisaríamos (ya que los proyectos de CDT 4 no son compatibles con los de 3.2; al abrir un proyecto antiguo lo actualiza). Sin embargo nos interesa tener el workspace con control de versiones porque así los pull se bajan todas las carpetas de las prácticas y no hay que ir una a una. | + | Yo estoy trabajando con un compañero en una asignatura, y tengo un servidor en bzr+ssh://direccion/repo/asignatura . Desafortunadamente mi compañero usa eclipse 3.2 y yo tengo instalado ya el 3.3, así que si ponemos todo el workspace bajo control de versiones nos pisaríamos (ya que los proyectos de CDT 4 no son compatibles con los de 3.2; al abrir un proyecto antiguo lo actualiza). Sin embargo nos interesa tener el workspace con control de versiones porque así los pull se bajan todas las carpetas de las prácticas y no hay que ir una a una. |
| − | ¿Solución? Una sería excluir cuando yo trabaje la configuración de los proyectos… O dejarme de eclipses nuevos y leches :). Pero hay otras. | + | ¿Solución? Una sería excluir cuando yo trabaje la configuración de los proyectos… O dejarme de eclipses nuevos y leches :). Pero hay otras. |
| − | Por ejemplo: hago el proyecto inicial en 3.2; creo el workspace, lo pongo bajo control de versiones, y lo subo con bzr push. Pero luego me creo un branch de ese workspace: bzr branch old-ws nuevo-ws. Ahora tengo una versión que "comparto" con mi compañero, old-ws, y una mía donde trabajo, nuevo-ws. | + | Por ejemplo: hago el proyecto inicial en 3.2; creo el workspace, lo pongo bajo control de versiones, y lo subo con bzr push. Pero luego me creo un branch de ese workspace: bzr branch old-ws nuevo-ws. Ahora tengo una versión que "comparto" con mi compañero, old-ws, y una mía donde trabajo, nuevo-ws. |
| − | Mis commits van a mi versión local, y cuando quiero pasarle los cambios me voy a old-ws y hago bzr merge ../nuevo-ws. El resultado: | + | Mis commits van a mi versión local, y cuando quiero pasarle los cambios me voy a old-ws y hago bzr merge ../nuevo-ws. El resultado: |
| − | M pr1/.project<br> M pr1/.settings/org.eclipse.cdt.core.prefs<br> M pr1/Debug/makefile<br> M pr1/Debug/objects.mk<br> M pr1/Debug/sources.mk<br> M pr1/src/escena.cpp<br> M pr1/src/escena.h<br> M pr1/src/skel.cpp<br>All changes applied successfully.<br>Los cambios están en el workspace antiguo y podría subirlos con bzr push directamente. Pero ojo! está machacando el .proyect y las preferencias de cdt porque detecta que son más nuevos; volvemos al problema original! | + | M pr1/.project<br> M pr1/.settings/org.eclipse.cdt.core.prefs<br> M pr1/Debug/makefile<br> M pr1/Debug/objects.mk<br> M pr1/Debug/sources.mk<br> M pr1/src/escena.cpp<br> M pr1/src/escena.h<br> M pr1/src/skel.cpp<br>All changes applied successfully.<br>Los cambios están en el workspace antiguo y podría subirlos con bzr push directamente. Pero ojo! está machacando el .proyect y las preferencias de cdt porque detecta que son más nuevos; volvemos al problema original! |
| − | No obstante puedo hacer: bzr revert pr1/.project y bzr revert pr1/.settings/org.eclipse.cdt.core.prefs, y ya solo subiría mis cambios en el código y no en los archivos de configuración del proyecto… | + | No obstante puedo hacer: bzr revert pr1/.project y bzr revert pr1/.settings/org.eclipse.cdt.core.prefs, y ya solo subiría mis cambios en el código y no en los archivos de configuración del proyecto… |
| − | Siempre puedo ver qué está pasando con bzr status en cada repo. | + | Siempre puedo ver qué está pasando con bzr status en cada repo. |
| − | En el antiguo: | + | En el antiguo: |
| − | bzr status<br>modified:<br> pr1/Debug/makefile<br> pr1/Debug/objects.mk<br> pr1/Debug/sources.mk<br> pr1/src/escena.cpp<br> pr1/src/escena.h<br> pr1/src/skel.cpp<br>pending merges:<br> Jisakiel 2007-11-04 funcionando anidar rectángulos<br> Jisakiel 2007-11-04 tocando lo de los rectángulos, por alguna razón no m...<br>Y en el nuevo, después de commitear en el antiguo y mergearme los cambios: | + | bzr status<br>modified:<br> pr1/Debug/makefile<br> pr1/Debug/objects.mk<br> pr1/Debug/sources.mk<br> pr1/src/escena.cpp<br> pr1/src/escena.h<br> pr1/src/skel.cpp<br>pending merges:<br> Jisakiel 2007-11-04 funcionando anidar rectángulos<br> Jisakiel 2007-11-04 tocando lo de los rectángulos, por alguna razón no m...<br>Y en el nuevo, después de commitear en el antiguo y mergearme los cambios: |
| − | bzr status<br>unknown:<br> pr1/.cdtbuild_initial<br> pr1/.cproject<br> pr1/.project_initial<br>pending merges:<br> Jisakiel 2007-11-04 problema del bzignore apañado<br> Jisakiel 2007-11-04 problema del bzignore apañado<br>Los .project de ambos son diferentes no obstante!. | + | bzr status<br>unknown:<br> pr1/.cdtbuild_initial<br> pr1/.cproject<br> pr1/.project_initial<br>pending merges:<br> Jisakiel 2007-11-04 problema del bzignore apañado<br> Jisakiel 2007-11-04 problema del bzignore apañado<br>Los .project de ambos son diferentes no obstante!. |
| − | estoy trabajando sobre este ejemplo de uso, ya contaré novedades y aclararé mis ideas según avance | + | estoy trabajando sobre este ejemplo de uso, ya contaré novedades y aclararé mis ideas según avance |
| − | Subir cambios | + | Subir cambios |
| − | bzr push bzr+ssh://<me>@bazaar.launchpad.net/~nombre-equipo/hdlorean/branch-concreto | + | bzr push bzr+ssh://<me>@bazaar.launchpad.net/~nombre-equipo/hdlorean/branch-concreto |
| − | Con el comando estás subiendo como usuario <me> al espacio del equipo. Si hay conflictos, al igual que pull, te avisa diciéndote que las versiones han divergido, que uses merge. | + | Con el comando estás subiendo como usuario <me> al espacio del equipo. Si hay conflictos, al igual que pull, te avisa diciéndote que las versiones han divergido, que uses merge. |
| − | Comandos útiles | + | Comandos útiles |
| − | Ver qué ha cambiado en un archivo | + | Ver qué ha cambiado en un archivo |
| − | bzr diff<br>Ver historia de revisiones (lista de mensajes y cambios) | + | bzr diff<br>Ver historia de revisiones (lista de mensajes y cambios) |
| − | bzr log<br>Deshacer un cambio | + | bzr log<br>Deshacer un cambio |
| − | bzr revert<br>Borrar un archivo | + | bzr revert<br>Borrar un archivo |
| − | OJO! queda versionado, nada de borrar temporales así! | + | OJO! queda versionado, nada de borrar temporales así! |
| − | bzr remove<br>Si os coláis y añadís un temporal, para que no se versione: | + | bzr remove<br>Si os coláis y añadís un temporal, para que no se versione: |
| − | bzr uncommit | + | bzr uncommit |
| − | OJITO CON ESTO!! Deshace la última revisión. Usad primero —dry-run !!!<br>Ver conflictos | + | OJITO CON ESTO!! Deshace la última revisión. Usad primero —dry-run !!!<br>Ver conflictos |
| − | bzr conflicts | + | bzr conflicts |
| − | Útil para ver por qué no tira merge.<br>Marcar conflictos como "resueltos" | + | Útil para ver por qué no tira merge.<br>Marcar conflictos como "resueltos" |
| − | bzr resolve | + | bzr resolve |
| − | Ignorar archivos: | + | Ignorar archivos: |
| − | Lista de archivos a ignorar. | + | Lista de archivos a ignorar. |
| − | .bzignore<br>Útil para que no haya que excluirlos a mano cuando eliges qué versionas. Así no ocupamos espacio ni ancho de banda de más (y creedme, si empiezas a dejar los .exe y .obj se come un montonazo porque se generan muchos). | + | .bzignore<br>Útil para que no haya que excluirlos a mano cuando eliges qué versionas. Así no ocupamos espacio ni ancho de banda de más (y creedme, si empiezas a dejar los .exe y .obj se come un montonazo porque se generan muchos). |
| − | Por ejemplo: | + | Por ejemplo: |
*.o<br>*~<br>*.tmp<br>*.py[co] | *.o<br>*~<br>*.tmp<br>*.py[co] | ||
| − | TODO: Escribir este archivo para nuestros chicos ;) Para que no haya que meter nada más de lo necesario (cuidado con las autotools que casi todo salvo configure.ac y Makefile.am se genera *solito* )<br>Ver qué has ignorado: | + | TODO: Escribir este archivo para nuestros chicos ;) Para que no haya que meter nada más de lo necesario (cuidado con las autotools que casi todo salvo configure.ac y Makefile.am se genera *solito* )<br>Ver qué has ignorado: |
| − | bzr ignored<br>Y otra cosa útil: | + | bzr ignored<br>Y otra cosa útil: |
| − | bzr add .bzrignore<br>bzr commit -m "Add ignore patterns" | + | bzr add .bzrignore<br>bzr commit -m "Add ignore patterns" |
| − | Para que el archivo de ignore también esté versionado ;). | + | Para que el archivo de ignore también esté versionado ;). |
| − | Interfaces gráficas (GUI) | + | Interfaces gráficas (GUI) |
| − | El que lo tenga en sus repos: bzr-config con sus ventanitas para configurarlo (no hace mucha falta, con hacer la inicialización…). | + | El que lo tenga en sus repos: bzr-config con sus ventanitas para configurarlo (no hace mucha falta, con hacer la inicialización…). |
| − | También está bzr-gtk. Creo que es todo lo que he contado, pero más automático (pinta iconitos para ver qué ha cambiado, puede hacer los merge con una herramienta de diff…). | + | También está bzr-gtk. Creo que es todo lo que he contado, pero más automático (pinta iconitos para ver qué ha cambiado, puede hacer los merge con una herramienta de diff…). |
| − | Incluso hay un plugin para eclipse; creo que falla con meter nombres de usuario y demás así que hay que tener la autenticación "automática", lo que es harina de otro percal: | + | Incluso hay un plugin para eclipse; creo que falla con meter nombres de usuario y demás así que hay que tener la autenticación "automática", lo que es harina de otro percal: |
| − | Clave pública subida al launchpad<br>ssh-agent corriendo<br>"algo" para que se añada automáticamente al iniciar sesión, o al menos que pida contraseña (investigando, ayúdenme! XD). Por esto digo que es más lioso, si no sería adecuadísimo.<br>Ambos estoy probándolos aún. | + | Clave pública subida al launchpad<br>ssh-agent corriendo<br>"algo" para que se añada automáticamente al iniciar sesión, o al menos que pida contraseña (investigando, ayúdenme! XD). Por esto digo que es más lioso, si no sería adecuadísimo.<br>Ambos estoy probándolos aún. |
| − | <br>Clave SSH - Necesario para subir Código | + | <br>Clave SSH - Necesario para subir Código |
| − | Mirad en el tutorial de launchpad, ya que es requisito del launchpad más que del propio bazaar. | + | Mirad en el tutorial de launchpad, ya que es requisito del launchpad más que del propio bazaar. |
| − | Fuentes | + | Fuentes |
| − | Para el que quiera mirar por su cuenta: | + | Para el que quiera mirar por su cuenta: |
| − | Página oficial, wikipedia. Recomiendo empezar por Bazaar en 5 minutos y Workflows para enterarse de qué va esto. | + | Página oficial, wikipedia. Recomiendo empezar por Bazaar en 5 minutos y Workflows para enterarse de qué va esto. |
También hay bastante en launchpad sobre su hosting de código, directamente aplicable a la propuesta modelo desarrollo: http://help.launchpad.net/FeatureHighlights/BazaarHosting y siguientes (2, 3 )<br> | También hay bastante en launchpad sobre su hosting de código, directamente aplicable a la propuesta modelo desarrollo: http://help.launchpad.net/FeatureHighlights/BazaarHosting y siguientes (2, 3 )<br> | ||
| + | |||
| + | fuente: http://hdlorean.wikidot.com/tutoriales:bazaar | ||
| + | |||
| + | [[Category:bazaar]] | ||
Revisió del 09:11, 23 maig 2011
Antes de nada, registraros en http://launchpad.net y http://launchpad.net/~hdlorean después; si no hay cosas que no os dejará hacer…
También necesitáis instalar bazaar. Con ubuntu: apt-get install bzr. Cuidado!; no es "bazaar" sino "bzr"; bzr es un fork también conocido como bazaar-ng del bazaar original, que a su vez es un fork de gnu arch.
También podéis probar el GUI.
Unos conceptos básicos: TODO
Configuración inicial
bzr whoami "Pedro Páramo <email@example.com>"
Así los commits tienen nombre.
Usar un repositorio LOCAL
Hacer tu propio branch, ver propuesta modelo desarrollo. Vale para cualquier cosa que queráis tener. No es obligatorio.
1. Os metéis en el directorio que queráis tener versionado.
2. Arrancar el repositorio (internamente: crea una carpeta oculta dentro).
bzr init
3. Añadir todo lo que encuentra en "." .
bzr add .
Alternativamente: meter uno a uno, o con patrones (*.cpp *.h etc).
POR FAVOR: No metáis temporales. Ver Ignorar archivos.
4. Ver qué estás haciendo, qué hay añadido / cambiado / etc.
bzr status
5. ¡APLICAR CAMBIOS!: Añadir esta versión al repo.
bzr commit -m "mensaje"
Si no pones el mensaje te abre un editor. La primera línea debe ser descriptiva; el resto es en detalle.
Congratz!!! El código ya está bajo versiones. Podéis ver Comandos útiles ahora para saber qué más se puede hacer.
Subir tu código a launchpad
Para copia de seguridad, tener varios equipos, etc.
bzr push bzr+ssh://<me>@bazaar.launchpad.net/~<me>/hdlorean/mine
Sube como tu usuario (<me>@…) al espacio tuyo (~<me>) una rama del proyecto. No estoy seguro si mine puede cambiarse por "mi nombre de branch". de hecho mine *es* el nombre de branch que le quiera dar yo.
TODO sincronizar portátil / sobremesa
Se parece a mezclar branches con tu grupo de trabajo: Primero lo subes a internete con bzr push, luego lo mezclas cambios de uno y otro con bzr merge, o alternativamente te bajas directamente en el que no tiene los nuevos con bzr pull.
Trabajar contra un repositorio compartido
Ver propuesta modelo desarrollo. Hay dos posibilidades, según tengas un "branch" o un "checkout". Con el primero haces commits locales sin internet; con el segundo no.
De fácil a difícil:
Con checkout (como svn)
Descargar
bzr checkout http://launchpad.net/~nombre-equipo/hdlorean/nombre-branch carpeta-destino
Modificar.
A partir de aquí, todo es igual que para un local repositorio local (bzr add, bzr commit, etc). Pero para hacer commit necesitas estar conectado a internet y te pedirá user / password.
Si al hacer commit alguien ha tocado en el repositorio ya, te obligará a bajarte los últimos cambios con update (y si hay conflictos te obliga a resolverlos) antes de subirlos.
CUIDADO! Si el checkout es del http, no debería dejarte subir nada salvo con bzr+ssh que va autenticado!!! Y no hemos especificado a dónde subirlo…
Invito a todo alma indómita que se meta a probar que esto funciona, y explicarme exactamente cómo. YO NO HE PROBADO ESTE MÉTODO AÚN!!!
Con branch
Lo que aquí cuento es aplicable a mezclar tu branch con el del equipo, y gestionar conflictos.
Hay dos formas de hacerlo: una, mezclar directamente sobre tu trabajo (parecido a svn update). La otra es bajarte el código del equipo en un branch y hacer un branch "de trabajo" de ese branch, para luego mezclarlos.
Descargar
bzr branch http://launchpad.net/nombre-equipo/hdlorean/branch-concreto
Lo de carpeta destino funciona por defecto. Alternativamente con bzr+ssh (más eficiente).
Desde este momento tienes un branch local que va asociado a dónde te lo has bajado.
Modificar
Igual que en local. Importante terminar con el commit, si no no has hecho nada!!
Bajarse cambios
bzr pull
Solo funciona si no hay cambios locales (cuidado, esto no es svn update, el merge no es automático). Por ejemplo, si al acabar de currar has subido con push, el siguiente paso puede ser un pull.
Mezclar branches (se hace en LOCAL siempre)
Pasar cambios de un branch a otro que tienes en el disco duro. Si un branch va en internet creo que se baja los últimos cambios, intenta mezclar con los tuyos y solo te avisa en los conflictos él solito.
bzr merge ruta-al-destino
bzr commit -m "mezclados branch sobre el que trabajaba en local y branch destino"
Atención al merge: ruta-al-destino es de dónde quieres coger los cambios. Por ejemplo:
Si tú tienes un origen (digamos un checkout de lo del equipo) y haces un branch para trabajar tú, el merge tendrías que hacerlo en el origen y contra el branch (cd origen; bzr merge ../branch-del-origen); al menos a mí me está funcionando así.
Si, sin embargo, estás trabajando contra el branch del equipo, los cambios los cogerías de ahí y por tanto tu ruta al destino sería bzr+ssh://<me>@bazaar.launchpad.net/~nombre-equipo/hdlorean/branch-concreto
Es el comando delicado así que hay que tener un poco de ojo hasta que nos aclaremos; recomiendo tener una copia de con lo que se trastee antes por si acaso…
Ejemplo práctico
Yo estoy trabajando con un compañero en una asignatura, y tengo un servidor en bzr+ssh://direccion/repo/asignatura . Desafortunadamente mi compañero usa eclipse 3.2 y yo tengo instalado ya el 3.3, así que si ponemos todo el workspace bajo control de versiones nos pisaríamos (ya que los proyectos de CDT 4 no son compatibles con los de 3.2; al abrir un proyecto antiguo lo actualiza). Sin embargo nos interesa tener el workspace con control de versiones porque así los pull se bajan todas las carpetas de las prácticas y no hay que ir una a una.
¿Solución? Una sería excluir cuando yo trabaje la configuración de los proyectos… O dejarme de eclipses nuevos y leches :). Pero hay otras.
Por ejemplo: hago el proyecto inicial en 3.2; creo el workspace, lo pongo bajo control de versiones, y lo subo con bzr push. Pero luego me creo un branch de ese workspace: bzr branch old-ws nuevo-ws. Ahora tengo una versión que "comparto" con mi compañero, old-ws, y una mía donde trabajo, nuevo-ws.
Mis commits van a mi versión local, y cuando quiero pasarle los cambios me voy a old-ws y hago bzr merge ../nuevo-ws. El resultado:
M pr1/.project
M pr1/.settings/org.eclipse.cdt.core.prefs
M pr1/Debug/makefile
M pr1/Debug/objects.mk
M pr1/Debug/sources.mk
M pr1/src/escena.cpp
M pr1/src/escena.h
M pr1/src/skel.cpp
All changes applied successfully.
Los cambios están en el workspace antiguo y podría subirlos con bzr push directamente. Pero ojo! está machacando el .proyect y las preferencias de cdt porque detecta que son más nuevos; volvemos al problema original!
No obstante puedo hacer: bzr revert pr1/.project y bzr revert pr1/.settings/org.eclipse.cdt.core.prefs, y ya solo subiría mis cambios en el código y no en los archivos de configuración del proyecto…
Siempre puedo ver qué está pasando con bzr status en cada repo.
En el antiguo:
bzr status
modified:
pr1/Debug/makefile
pr1/Debug/objects.mk
pr1/Debug/sources.mk
pr1/src/escena.cpp
pr1/src/escena.h
pr1/src/skel.cpp
pending merges:
Jisakiel 2007-11-04 funcionando anidar rectángulos
Jisakiel 2007-11-04 tocando lo de los rectángulos, por alguna razón no m...
Y en el nuevo, después de commitear en el antiguo y mergearme los cambios:
bzr status
unknown:
pr1/.cdtbuild_initial
pr1/.cproject
pr1/.project_initial
pending merges:
Jisakiel 2007-11-04 problema del bzignore apañado
Jisakiel 2007-11-04 problema del bzignore apañado
Los .project de ambos son diferentes no obstante!.
estoy trabajando sobre este ejemplo de uso, ya contaré novedades y aclararé mis ideas según avance
Subir cambios
bzr push bzr+ssh://<me>@bazaar.launchpad.net/~nombre-equipo/hdlorean/branch-concreto
Con el comando estás subiendo como usuario <me> al espacio del equipo. Si hay conflictos, al igual que pull, te avisa diciéndote que las versiones han divergido, que uses merge.
Comandos útiles
Ver qué ha cambiado en un archivo
bzr diff
Ver historia de revisiones (lista de mensajes y cambios)
bzr log
Deshacer un cambio
bzr revert
Borrar un archivo
OJO! queda versionado, nada de borrar temporales así!
bzr remove
Si os coláis y añadís un temporal, para que no se versione:
bzr uncommit
OJITO CON ESTO!! Deshace la última revisión. Usad primero —dry-run !!!
Ver conflictos
bzr conflicts
Útil para ver por qué no tira merge.
Marcar conflictos como "resueltos"
bzr resolve
Ignorar archivos:
Lista de archivos a ignorar.
.bzignore
Útil para que no haya que excluirlos a mano cuando eliges qué versionas. Así no ocupamos espacio ni ancho de banda de más (y creedme, si empiezas a dejar los .exe y .obj se come un montonazo porque se generan muchos).
Por ejemplo:
- .o
*~
*.tmp
*.py[co]
TODO: Escribir este archivo para nuestros chicos ;) Para que no haya que meter nada más de lo necesario (cuidado con las autotools que casi todo salvo configure.ac y Makefile.am se genera *solito* )
Ver qué has ignorado:
bzr ignored
Y otra cosa útil:
bzr add .bzrignore
bzr commit -m "Add ignore patterns"
Para que el archivo de ignore también esté versionado ;).
Interfaces gráficas (GUI)
El que lo tenga en sus repos: bzr-config con sus ventanitas para configurarlo (no hace mucha falta, con hacer la inicialización…).
También está bzr-gtk. Creo que es todo lo que he contado, pero más automático (pinta iconitos para ver qué ha cambiado, puede hacer los merge con una herramienta de diff…).
Incluso hay un plugin para eclipse; creo que falla con meter nombres de usuario y demás así que hay que tener la autenticación "automática", lo que es harina de otro percal:
Clave pública subida al launchpad
ssh-agent corriendo
"algo" para que se añada automáticamente al iniciar sesión, o al menos que pida contraseña (investigando, ayúdenme! XD). Por esto digo que es más lioso, si no sería adecuadísimo.
Ambos estoy probándolos aún.
Clave SSH - Necesario para subir Código
Mirad en el tutorial de launchpad, ya que es requisito del launchpad más que del propio bazaar.
Fuentes
Para el que quiera mirar por su cuenta:
Página oficial, wikipedia. Recomiendo empezar por Bazaar en 5 minutos y Workflows para enterarse de qué va esto.
También hay bastante en launchpad sobre su hosting de código, directamente aplicable a la propuesta modelo desarrollo: http://help.launchpad.net/FeatureHighlights/BazaarHosting y siguientes (2, 3 )