El Repositorio del CVS

El c�digo fuente de Postgres se almacena y administra utiliando el sistema de gesti�n de c�digo CVS.

Hay al menos dos m�todos, CVS an�nimo y CVSup, utilizables para copiar el �rbol del c�digo de CVS desde el servidor de Postgres a su m�quina local.

Organizaci�n del �rbol de CVS

NotaAuthor
 

Escrito por Marc G. Fournier el 1998-11-05.

NotaTraductor
 

Traducido por Equipo de traducci�n de PostgreSQL el 2001-03-14.

(N. del T: Ismael Olea ha escrito un estupendo documento llamado "Micro-c�mo empezar a trabajar con cvs", muy facil de entender y de utilizar, y que puede resultar muy interesante para los que s�lo deseen utilizar un cliente de CVS de modo gen�rico. Como �l tambi�n colabora en la traducci�n, no puedo por menos de recomendarlo.

Lo pueden conseguir en su p�gina personal y desde luego pidiendoselo directamente a �l olea@hispafuentes.com. Fin de la N. del T.)

El comando cvs checkout tiene un indicador (flag), -r, que le permite comprobar una cierta revisi�n de un m�dulo. Este indicador facilita tambi�n, por ejemplo, recuperar las fuentes que formaban la release 1.0 del m�dulo `tc' en cualquier momento futuro:

$ cvs checkout -r REL6_4 tc
   
Esto es utilizable, por ejemplo, si alguien asegura que hay un error (un bug) en esa release, y usted no es capaz de encontrarlo en la copia de trabajo actual.

Sugerencia

Tambi�n puede usted comprobar un m�dulo conforme era en cualquier momento dado utilizando la opci�n -D.

Cuando etiquete usted m�s de un fichero con la misma etiqueta, puede usted pensar en las etiquetas como "una l�nea curva que recorre una matriz de nombres de ficheros contra n�mero de revisi�n". Digamos que tenemos 5 ficheros con las siguientes revisiones:

             fich1   fich2   fich3   fich4   fich5
     
             1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG (etiqueta)
             1.2*-   1.2     1.2    -1.2*-
             1.3  \- 1.3*-   1.3   / 1.3
             1.4          \  1.4  /  1.4
                           \-1.5*-   1.5
                             1.6
   
donde la etiqueta "TAG" har� referencia a fich1-1.2, fich2-1.3, etc.

Nota

Para crear la rama de una nueva release, se emplea de nuevo el comando -b, del mismo modo anterior.

De este modo, para crear la release v6.4, hice lo siguiente:

$ cd pgsql
$ cvs tag -b REL6_4
   
lo cual crear� la etiqueta y la rama para el �rbol RELEASE.

Ahora, para aquellos con acceso CVS, tambi�n es sencillo. Primero, cree dos subdirectorios, RELEASE y CURRENT, de forma que no mezcle usted los dos. A continuaci�n haga:

cd RELEASE
cvs checkout -P -r REL6_4 pgsql
cd ../CURRENT
cvs checkout -P pgsql
   
lo que dar� lugar a dos �rboles de directorios, RELEASE/pgsql y CURRENT/pgsql. A partir de este momento, CVS tomar� el control de qu� rama del repositorio se encuentra en cada �rbol de directorios, y permitir� actualizaciones independientes de cada �rbol.

Si usted s�lo est� trabajando en el �rbol fuente CURRENT h�galo todo tal como empezamos antes etiquetando las ramas de la release. If you are only working on the CURRENT source tree, you just do everything as before we started tagging release branches.

Una vez que usted realiza el checkout (igualado, comprobaci�n, descarga) inicial en una rama,

$ cvs checkout -r REL6_4
   
todo lo que usted haga dentro de esa estructura de directorios se restringe a esa rama. Si usted aplica un patch a esa estructura de directorios y hace un
cvs commit
   
mientras usted se encuentra dentro de ella, el patch se aplica a esa rama y s�lo a esa rama.