| | 1 | = Acta videoconferencia 23 Febrero 2011 = |
| | 2 | == Solución problema de creación de imágenes (CRC) == |
| | 3 | |
| | 4 | El problema al crear las imágenes en el repositorio con partclone se debía a que el script que genera los ficheros torrent de las imágenes las bloqueba mientras estaba creándose la imagen. Hay que decidir un mecanismo para evitar que los dos procesos trabajen sobre la imagen a la vez. Se comentan varias soluciones: |
| | 5 | |
| | 6 | |
| | 7 | * Utilizar un fichero de bloqueo de la imagen que se consulte antes de bloquearla. Se han creado las funciones ogLockImagen, ogUnlockImage y isImageLocked. Habría que decidir que que momenso se bloquea: al crearla, al crear el fichero torrent, mientras está restaurando algún cliente,... |
| | 8 | * Crear las imágenes nuevas con una extensión distinta, ej .new, o incluso con un número de versión. Al finalizar el proceso de creación de imágenes se renombraría la imagen actual a .ant y la imagen .new a la extensión normal. |
| | 9 | |
| | 10 | Se decide conjugar las dos formas. |
| | 11 | |
| | 12 | |
| | 13 | Se comenta que los controles se hagan a nivel de script y no afecten a las funciones, de manera que cada persona pueda utilizar el mecanismo que le venga mejor. |
| | 14 | |
| | 15 | |
| | 16 | |
| | 17 | == Reducción/ampliación de Sistema de Ficheros == |
| | 18 | |
| | 19 | Al crear imágenes se usa la función que reduce el sistema de ficheros. |
| | 20 | |
| | 21 | |
| | 22 | Era necesario para partimage pero no se está seguro que lo sea para partclone. Se harán pruebas para comprobarlo y si no es necesario se eliminará este paso de los script de creación y resturación de imágenes. |
| | 23 | |
| | 24 | |
| | 25 | == Script de actualización de la rama testing == |
| | 26 | |
| | 27 | Partiendo del script de actualización de la rama trunk se creará uno para la rama testing, de manera que se facilite la actualización de una versión del svn a otra. |
| | 28 | |
| | 29 | |
| | 30 | == La rama testing se pasará al trunk == |
| | 31 | Ya que la rama testing soluciona problemas que todavía aparecen en la rama trunk y ofrece más funcionalidades se decide pasar la rama testing al trunk y seguir estabilizando desde allí. |
| | 32 | |
| | 33 | |
| | 34 | Se creará un tag con el contenido actual del trunk |
| | 35 | |
| | 36 | |
| | 37 | Se creará una copia del trunk a la rama version 1.0 y allí se unirá el código del trunk con la testing. |
| | 38 | |
| | 39 | |
| | 40 | La pruebas se pueden seguir realizando como hasta ahora (instalador de la rama testing) hasta que la rama versión 1.0 tenga unidos los dos códigos. |
| | 41 | |
