Para comenzar, seguiré la siguiente línea de trabajo:
Si el guía trabaja de una forma, intenta trabajar como tu guía hasta que te sientas suficientemente cómodo para seguir tu propio camino.
Lo primero es definir la estructura de directorios de acuerdo al flujo de trabajo. En este caso, seguiré la forma en que Alvaro lo hace.
pgsql/
source
install
build
Dentro de source, un directorio por cada versión de trabajo. Alvaro maneja múltiples versiones porque es su trabajo. Yo sólo necesito 2: la rama principal de desarrollo (CVS HEAD) y el árbol para mi proyecto: autovacumm. Similar caso sucede para los directorios install y build, para la instalación y contrucción de los programas, respectivamente.
Tengo algunas alternativas para trabajar. Mantener vía cvs la rama principal, y en dicha copia manejarla con Mercurial. Así, por cada actualización (cvs update), aplicaré los cambios en el repositorio con Mercurial (hg commit).
El repositorio de trabajo, entonces, es una rama de mi repositorio principal, la cual la puedo crear con hg clone. Cada cierto tiempo, puedo sincronizar ambos repositorios y si se presentan conflictos, resolverlos tan pronto como sea posible; en vez de esperar hasta el final, donde puede ser más difícil conciliar los cambios. Esto vía hg pull desde el repositorio de trabajo y hg merge.
Como alternativa de trabajo, puedo manejar una cola de parches, con la extensión mq. Esto es, antes de sincronizar ambos repositorios, extraer los cambios en el repositorio de trabajo (vía hg qpop -a), sincronizar y posteriormente volver a aplicar los cambios (vía hg qpush -a).
Con cualquiera de las dos alternativas, y en caso de conflicto, puedo mezclar visualmente los cambios con meld, que es ejecutado automáticamente cuando surge un conflicto.
Lo siguiente es obtener el código fuente. Las instrucciones para obtener el código vía cvs es distinta a las que usualmente he empleado en otros proyectos. Ellos exportan el árbol con toda la historia de cvs vía rsync. Sólo necesito una imagen de lo que hay en el repositorio en un momento determinado. Mi tiempo cero de desarrollo es cuando obtengo el repositorio por primera vez, y puedo abstraerme del historial antiguo.
Siguiendo la estructura de directorios y el flujo de trabajo de Alvaro (aunque con ligeras modificaciones para manejarlos con Mercurial), puedo usar los mismos scripts que él, de los cuales comentaré mas adelante.
Está bastante buena la idea del autovacuum. Pero siempre me he preguntado, porque se estira tanto a veces la base de datos??. Estoy hablando de diferencias de gigas, entre un antes y un después de un vacuum FULL.
Y por otro lado, no se necesita ser estudiante para participar en un proyecto??.
Es el costo de MVCC (Multi-Version Concurrency Control), el cual permite evitar los conflictos o bloqueos cuando se accede concurrentemente a un mismo objeto para lectura y escritura.
En términos generales, cuando se produce una actualización de una tupla, Postgresql crea una nueva versión de esa tupla y expira la anterior. Es decir, se tienen 2 versiones de la misma tupla. Si no manejara 2 versiones, tendría que bloquear la tupla mientras actualiza, impidiendo que se puedan realizar consultas donde intervenga la tupla bloqueada.
Esto permite que Postgresql pueda atender rápidamente las consultas, pero requiere espacio adicional. Y para ello está VACUUM, cuyo objeto es mantener la base de datos en un tamaño adecuado, y recupera el espacio buscando aquellas partes que ya no se necesitan.
Olvidé responder la segunda pregunta:
Efectivamente se necesita ser estudiante. Como decía anteriormente:
:-)
Por que el uso de Mercurial?
que ventajes le trae el uso de él, por sobre CVS o SVC
Más que las ventajas de Mercurial sobre CVS o SVN, es mejor expresarlo en términos de sistemas de control de versiones distribuidos versus centralizados.
En este caso particular, yo no puedo incorporar mis cambios al repositorio de Postgresql, pero sin embargo debo trabajar con él. Una vez que termine mi trabajo, y si es bueno o aceptable, tendré que enviar las diferencias con mis cambios.
Luego, necesito una forma que mi rama de trabajo mantenga mis cambios y a la vez, mantenerlo sincronizado con el desarrollo de Postgresql. Si no mantengo sincronizados los cambios, en el futuro será mucho más difícil hacerlo, porque tal vez sean demasiados.
Además, para mi trabajo, necesito poder controlar atómicamente cada cambio, porque en algún momento lo necesitaré. Eso no lo podría hacer con CVS o SVN; salvo que tenga una copia local del repositorio. Es posible, en casos como Postgresql, pero es más fácil (para mí) con un control de versiones distribuidos.
CVS en sí, carece de varias características deseables. Por ejemplo, si necesitas renombrar un archivo, lo eliminas y lo vuelves a crear; pero perdiste la historia de ese archivo; en ninguna parte puedes determinar que ese archivo en realidad se renombró. Además, cuando comprometes los cambios no son atómicos. Por ejemplo, si realizo un commit de 5 archivos, para CVS son 5 operaciones distintas; siendo que pertenecen a un mismo grupo.
Además, crear y mantener un repositorio en Mercurial es sencillo. En mi humilde opinión, mucho más que CVS o SVN; porque no necesitas un servidor.
Hace un tiempo escribí el uso de Mercurial. Allí también aparecen algunos enlaces que son bastante ilustrativos.
Muchas gracias por la aclaración, averiguare más y lo provare :)