               Perforce en el contexto del desarrollo de FreeBSD

  Scott Long

   <scottl@FreeBSD.org>
             

   Revision: 43184

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   CVSup is a registered trademark of John D. Polstra.

   Many of the designations used by manufacturers and sellers to distinguish
   their products are claimed as trademarks. Where those designations appear
   in this document, and the FreeBSD Project was aware of the trademark
   claim, the designations have been followed by the "(TM)" or the "(R)"
   symbol.

   2013-11-13 por hrs.
   [ Split HTML / Single HTML ]

     ----------------------------------------------------------------------

   Tabla de contenidos

   1. Introduccion

   2. Los comienzos

   3. Clientes

   4. Sincronizaciones

   5. Ramas

   6. Integraciones

   7. Aplicacion de cambios en el repositorio

   8. Edicion

   9. Cambios, descripciones e historial

   10. "diffs"

   11. Anadir o eliminar ficheros

   12. El trabajo con "diffs"

   13. Cambiar nombres de ficheros

   14. Interacciones entre el CVS de FreeBSD y Perforce

   15. Funcionamiento sin conexion de red

   16. Consideraciones finales para el "Google Summer of Code"

1. Introduccion

   El proyecto FreeBSD utiliza el sistema de control de versiones Perforce
   para gestionar proyectos experimentales que todavia no estan listos para
   ser incluidos en el repositorio principal de CVS.

  1.1. Disponibilidad, documentacion y recursos

   Aunque que el producto Perforce es un producto comercial, el software
   cliente que se encarga de interactuar con el servidor se distribuye
   libremente. Pueden descargarse versiones binarias del mismo desde el sitio
   web de Perforce: http://www.perforce.com/perforce/loadprog.html.

   Existe un cliente grafico, pero la mayoria de la gente utiliza la
   aplicacion de linea de ordenes, p4. Este documento trata sobre el uso de
   dicha herramienta para la linea de ordenes.

   En http://www.perforce.com/perforce/technical.html encontrara
   documentacion "online" detallada.

   Se recomienda encarecidamente leer la "guia de usuario" y el "manual de
   Perforce". La aplicacion p4 dispone de una extensa ayuda "online" a la que
   puede accederse mediante la orden p4 help.

   El servidor FreeBSD Perforce se encuentra en perforce.freebsd.org, puerto
   1666. Puede navegar por el repositorio desde http://perforce.freebsd.org.
   Ciertas partes del repositorio se exportan automaticamente hacia diversos
   servidores CVSup.

2. Los comienzos

   El primer paso para utilizar Perforce consiste en obtener una cuenta en el
   servidor. Si ya dispone de una cuenta en FreeBSD.org entre en freefall y
   ejecute el siguiente comando utilizando una contrasena distinta del acceso
   de su FreeBSD o de cualquier otro mecanismo de autenticacion SSH:

 % /usr/local/bin/p4newuser

   Por supuesto si no tiene una cuenta en FreeBSD.org necesitara coordinarse
   con su mentor.

   El siguiente paso consiste en establecer las variables de entorno que
   necesita p4 y en verificar que puede conectarse al servidor. Es necesario
   especificar la variable P4PORT para realizar cualquier operacion. Dicha
   variable indica el servidor Perforce con el que se va a trabajar. En el
   caso del Proyecto FreeBSD, creela con el siguiente valor:

 % export P4PORT=perforce.freebsd.org:1666

  Nota:

   Los usuarios con acceso "shell" al "cluster" FreeBSD.org pueden querer
   encapsular el protocolo cliente-servidor de Perforce a traves de un tunel
   SSH, en cuyo caso la variable de arriba deberia establecerse al valor
   localhost.

   El servidor FreeBSD tambien necesita que se establezcan las variables
   P4PASSWD y P4USER. Utilice el nombre de usuario y la contrasena anteriores
   del siguiente modo:

 % export P4USER=nombre_de_usuario
 % export P4PASSWD=contrasena

   Compruebe que todo funciona mediante la siguiente orden:

 % p4 info

   A resultas de esta orden deberia ver informacion referente al servidor. Si
   no es asi compruebe que la variable P4PORT tiene el valor correcto.

3. Clientes

   El sistema Perforce proporciona acceso al repositorio y mantiene el estado
   del cliente de forma individualizada. En terminos de Perforce, un cliente
   es una especificacion que asocia [1] ficheros y directorios desde el
   repositorio hasta la maquina local. Cada usuario puede poseer varios
   clientes, y cada cliente puede acceder a distintas partes del repositorio
   (incluso a varias partes que se solapan entre si). El cliente tambien
   especifica el directorio raiz del arbol de directorios sobre el que se
   realiza la asociacion y la maquina donde efectivamente esta dicho arbol.
   Es por esto que si pretende trabajar en varias maquinas tendra que usar
   varios clientes.

   Puede acceder a los clientes mediante p4 client. Si se ejecuta esta orden
   sin argumentos aparece una plantilla del cliente dentro de un editor,
   permitiendo de esta forma crear un nuevo cliente. Los campos importantes
   de esta plantilla se explican a continuacion:

   Client:

           Este es el nombre de la especificacion del cliente. Puede ser
           cualquier cosa, pero debe ser una cadena unica dentro del servidor
           Perforce. Suelen usarse nombres como
           nombre_de_usuario_nombre_de_maquina, que permite identificar
           facilmente a los clientes cuando se navega por ellos. Por defecto
           hay ya un nombre, que se corresponde con el nombre de la maquina.

   Description:

           Este campo suele consistir en un breve texto descriptivo que ayude
           a identificar al cliente.

   Root:

           Se trata del directorio local que actuara como directorio raiz
           para todos los ficheros dentro de la asociacion en el cliente.
           Debe ser una localizacion unica dentro del sistema de ficheros que
           no se solape con otros ficheros o clientes Perforce.

   Options:

           La mayoria de las opciones por defecto son correctas y validas
           para todo el mundo, aunque suele ser recomendable comprobar que
           esten activadas las opciones compress y rmdir y que no tienen el
           prefijo no. Los detalles de cada una de estas opciones estan en la
           documentacion de Perforce.

   LineEnd:

           Este parametro gestiona las conversiones CR-LF y debe dejarse tal
           cual salvo que sus necesidades especificas requieran cambiarlo.

   View:

           Aqui es donde estan las asociaciones de ficheros servidor-a-local.
           El valor por defecto es:

 //depot/... //cliente/...

           Esto asociara por completo el repositorio Perforce al directorio
           Root del cliente. NO USE ESTE VALOR POR DEFECTO. El repositorio de
           FreeBSD es enorme e intentar asociarlo y sincronizarse con dicho
           repositorio tardara muchisimo y consumira enormes recursos. Asocie
           solamente la seccion del repositorio en la que va a trabajar. Por
           ejemplo, hay un arbol para el proyecto smpng en
           //depot/projects/smpng. Una asociacion en ese caso seria algo asi:

 //depot/projects/smpng/... //cliente/...

           Los ... deben tomarse literalmente tal cual estan. Es un dialecto
           de Perforce para decir "este directorio y todos los ficheros y
           directorios por debajo de el.".

           Una "vista" (View) puede contener multiples asociaciones. Vamos a
           suponer que quiere asociar los arboles de SMPng y de NFS. Su
           "View" seria algo asi:

 //depot/projects/smpng/... //cliente/smpng/...
           //depot/projects/nfs/... //cliente/nfs/...

           Recuerde que cliente es el nombre del cliente que se especifico en
           la seccion Client, pero en la seccion View ademas se utiliza para
           resolver al directorio especificado en la seccion Root.

           Tambien tenga en cuenta que el mismo fichero o directorio no puede
           asociarse mas de una vez dentro de una unica vista. La orden del
           siguiente ejemplo no es correcta y producira resultados
           imprevistos:

 //depot/projects/smpng/... //cliente/smpng-esto/...
           //depot/projects/smpng/... //cliente/smpng-lo_otro/...

           Las "vistas" son la parte compleja del proceso de aprendizaje de
           Perforce, asi que no tenga miedo de hacer tantas preguntas como
           estime oportunas.

   Puede listar los clientes existentes mediante p4 clients. Puede listarlos
   sin que sufran modificaciones mediante p4 client -o nombre_cliente.

   Siempre que se interactue con ficheros en Perforce la variable de entorno
   P4CLIENT debe contener al nombre del cliente que se esta utilizando, es
   decir:

 % export P4CLIENT=nombredemicliente

   Fijese en que las asociaciones del cliente en el repositorio no son
   exclusivos; varios clientes pueden estar asociados en la misma zona del
   respositorio. Esto permite el trabajo en equipo sobre el mismo codigo,
   permitiendo que distintas personas accedan y modifiquen la misma parte del
   respositorio.

4. Sincronizaciones

   Una vez definida la especificacion del cliente y una vez establecida la
   variable de entorno P4CLIENT, el siguiente paso consiste en recuperar los
   ficheros para el cliente en cuestion desde el servidor hasta la maquina
   local. Esto se realiza con p4 sync, el cual indica a Perforce que
   sincronice los ficheros locales con los del repositorio. La primera vez
   que se ejecuta descargara todos los ficheros. Las siguientes ejecuciones
   solo descargaran aquellos ficheros que hayan cambiado desde la ultima
   ejecucion de la orden. Gracias a esto es posible sincronizar sus fuentes
   con las de otras personas con las que este trabajando.

   Las operaciones de sincronizacion solo atanen a aquellos ficheros cuyas
   modificaciones han sido transmitidas a Perforce. Si se modifica o borra un
   fichero en local sin informar de ello al servidor la ejecucion de un
   "sync" no reflejara dichos cambios. No obstante, la ejecucion de p4 sync
   -f sincrozara incondicionalmente todos los ficheros, sin que importe su
   estado. Esto resulta util para solucionar problemas cuando se cree que el
   arbol pueda haber sufrido algun tipo de corrupcion.

   Puede sincronizarse parte del arbol o del cliente especificando una ruta
   relativa a la orden "sync". Por ejemplo, para sincronizar solo el
   directorio ufs del proyecto smpng ejecute lo siguiente:

 % cd raizdelproyecto/smpng
 % p4 sync src/sys/ufs/...

   El uso de rutas locales relativas funciona en muchas otras ordenes p4.

5. Ramas

   Una de las caracteristicas mas interesantes de Perforce es la posibilidad
   de crear ramas. Las ramas son muy sencillas de crear y tambien resulta muy
   facil mover cambios entre distintas ramas (como se vera mas adelante). Las
   ramas tambien nos permiten realizar trabajos muy experimentales dentro de
   un entorno de "sandbox", sin necesidad de tener que preocuparnos por las
   colisiones con otros usuarios o por desestabilizar el arbol principal.
   Ademas, las ramas proporcionan el aislamiento necesario frente a los
   errores que se cometen cuando se aprende a manejar el sistema Perforce.
   Vistas estas ventajas es logico que cada proyecto disponga de su propia
   rama y en FreeBSD recomendamos encarecidamente este esquema. Tambien se
   recomienda la aplicacion frecuente de los cambios realizados.

   El repositorio Perforce (conocido como el "deposito", o "depot" en la
   jerga de Perforce) es un unico arbol plano. Se accede a cada fichero a
   traves de una sencilla ruta bajo el directorio //depot, tanto si se trata
   de un fichero de nueva creacion como si proviene de una ramificacion. Esto
   supone una gran diferencia con respecto a sistemas como CVS, donde cada
   rama se encuentra en la misma ruta que su rama padre. En Perforce el
   servidor mantiene las relaciones entre los ficheros padre e hijo, pero los
   ficheros en si estan bajo sus propias rutas.

   El primer para para crear una rama consiste en crear una especificacion de
   rama. Es similar a la especificacion de un cliente, pero se crea mediante
   la orden p4 branch nombre_de_rama.

   Veamos los campos mas importantes:

   Branch

           El nombre de la rama. Puede ser cualquier nombre, pero debe ser
           unico en el repositorio. La convencion que se usa en FreeBSD es
           nombre_de_usuario_nombre_del_proyecto.

   Description

           Puede poner aqui un texto simple que describa la rama.

   View

           Esto es la asociacion de la rama. En lugar de asociar desde el
           "deposito" hacia la maquina local como una asociacion de cliente,
           se crea una asociacion entre la rama padre y la rama hija dentro
           del "deposito". Por ejemplo, puede querer crear una rama del
           proyecto smpng. La asociacion resultaria en algo parecido a esto:

 //depot/projects/smpng/... //depot/projects/mi-super-smpng/...

           O puede crear una rama totalmente nueva a partir de las fuentes de
           FreeBSD:

 //depot/vendor/freebsd/... //depot/projects/mi-nuevo-proyecto/...

           Esto asociara el HEAD del arbol de FreeBSD a su nueva rama.

   La creacion de la especificacion de rama unicamente graba la
   especificacion en si misma dentro del servidor. No modifica el "deposito"
   ni cambia ningun fichero. El directorio que se declara en la rama
   permanece vacio en el servidor hasta que se comience a llenar.

   Para rellenar la rama primero debemos editar el cliente con la orden p4
   client y asegurarnos de que el directorio de rama esta asociado en el
   cliente. Puede ser necesario anadir una linea View como esta:

 //depot/projects/mi-nuevo-proyecto/... //micliente/mi-nuevo-proyecto/...

   El siguiente paso consiste en ejecutar p4 integrate, como se describe en
   la siguiente seccion.

6. Integraciones

   "Integracion" es el termino que se utiliza en Perforce para describir la
   accion de mover cambios desde una parte del "deposito" a otra. Se suele
   realizar junto con las ordenes creacion y mantenimiento de ramas. Una
   integracion es necesaria cuando se quiere rellenar inicialmente una rama y
   cuando se quieren mover cambios realizados en la rama padre hacia la rama
   hija, o de la la rama hija a la padre. Un caso muy comun es la integracion
   periodica desde el arbol original de FreeBSD hacia la rama hija propia del
   usuario. El servidor Perforce mantiene el estado de los cambios en cada
   rama y sabe cuando hay cambios que pueden integrarse de una rama a otra.

   La forma mas comun de hacer una integracion se muestra en la siguiente
   orden:

 % p4 integrate -b nombrederama

   nombrederama es el nombre que se ha dado a la especificacion de rama, tal
   y como se explico en la seccion anterior. Esta orden indica a Perforce que
   busque cambios en la rama padre que todavia no se hayan aplicado a la rama
   hija. En base a los cambios encontrados se prepara un listado de
   diferencias a aplicar. Si la integracion se realiza por primera vez sobre
   una rama (por ejemplo cuando se realiza una operacion de rellenado
   inicial) los ficheros de la rama padre simplemente se copiaran en la
   ubicacion en la rama hija de la maquina local.

   Una vez que la operacion de integracion ha finalizado se debe ejecutar p4
   resolve, que aplicara los cambios y resolvera posibles conflictos. Los
   conflictos puede surgir debido a cambios que se solapan al encontrarse
   tanto en fichero de la rama padre como en la copia del fichero de la rama
   hija. Normalmente no suelen aparecer conflictos y Perforce puede calcular
   rapidamente como unir los cambios. Para ejecutar una operacion de
   resolucion ("resolve") utilice las siguientes ordenes:

 % p4 resolve -as
 % p4 resolve

   La primera invocacion indica a Perforce que una automaticamente los
   cambios y que acepte aquellos ficheros que no den conflictos. La segunda
   invocacion permite inspeccionar cada fichero con conflictos y resolver de
   forma manual dichas incompatiblidades.

   Una vez hecha la integracion de los ficheros llega el momento de aplicar
   los cambios al repositorio. Para ello se emplearemos la orden p4 submit,
   cuyo uso se explica en la siguiente seccion.

7. Aplicacion de cambios en el repositorio

   Los cambios que se han realizado en local se deben aplicar en el contenido
   del servidor Perforce para mayor seguridad frente a perdidas y para que
   otras personas puedan acceder a dichos cambios; esto se hace con la orden
   p4 submit. Cuando se ejecuta esta orden se abre una plantilla ("submit
   template") en el editor. FreeBSD dispone de una platilla personalizada, de
   la que a continuacion se explican los campos mas importantes:

 Description:
         <enter description here>
         PR:
         Submitted by:
         Reviewed by:
         Approved by:
         Obtained from:
         MFP4 after:

   es decir

 Descripcion:
        <Introduzca una descripcion>
        PR:
        Enviado por:
        Revisado por:
        Aprobado por:
        Obtenido de:
        MFP4 tras:

   Se considera una buena practica proporcionar al menos dos o tres frases
   que describan los cambios entregados. Deberia declarar aqui que hacen
   dichos cambios, por que se han hecho de esa forma o que problemas intenta
   resolver con ellos. Tambien conviene explicar que APIs cambian y que otros
   efectos secundarios pueden tener. Este texto debe sustituir a la linea
   <enter description here> que aparece en la plantilla. Debe recubrir las
   lineas y comenzar cada linea con una tabulacion. Las etiquetas de mas
   abajo son especificas de FreeBSD y puede eliminarlas si no resultan utiles
   o apropiadas en su contexto.

 Files:

   Este campo se rellena automaticamente con todos los ficheros que el
   cliente etiqueto en el servidor con estados de adicion, borrado,
   integracion o edicion. Le aconsejamos que revise esta lista y elimine de
   ella los ficheros que todavia no esten listos.

   Una vez guardada la sesion de su editor tiene lugar la entrega de los
   datos al servidor. Esto significa que las copias locales de los ficheros
   entregados se enviaran al servidor. Si algo va mal durante este proceso se
   cancelara la entrega y se avisara al usuario de que la entrega se ha
   convertido en una lista de cambios que deben corregirse y reenviarse. Las
   entregas son atomicas, es decir, si un fichero falla la entrega se cancela
   en su totalidad.

   Los cambios efectuados en el servidor no pueden cancelarse una vez hechos,
   pero si que pueden cancelarse si, dentro aun del editor, se sale de el sin
   cambiar el texto del campo Description. Perforce se quejara la primera vez
   que intente salir y le devolvera al editor. Si sale por segunda vez el
   editor cancelara la operacion. Devolver el repositorio al estado anterior
   a un cambio ya efectuado es un proceso muy complicado y no hay un
   procedimiento estandar, por lo que depende del caso concreto.

8. Edicion

   En el servidor se almacena y mantiene el estado de cada fichero del
   cliente. Para evitar colisiones entre distintas personas trabajando al
   mismo tiempo en el mismo fichero Perforce presta atencion a que ficheros
   estan abiertos en modo de edicion, y utiliza esa informacion para poder
   gestionar posteriormente las operaciones de entrega, las sincronizaciones
   y las integraciones.

   Para abrir un fichero para editarlo utilice p4 edit de la siguiente forma:

 % p4 edit nombredefichero

   Esto marca el fichero en el servidor con el estado de edicion, lo que
   permite entregar el fichero posteriormente una vez realizados los cambios
   oportunos, o lo etiqueta como de tratamiento especial cuando se esta
   efectuando una operacion de integracion o sincronizacion. Tenga en cuenta
   que la edicion no es exclusiva en Perforce. Varias personas pueden tener
   el mismo fichero en estado de edicion (sera informado de ello si es
   necesario cuando ejecute edit), pero podra entregar sus cambios incluso
   cuando haya otras personas que tengan ese fichero en estado de edicion.

   Cuando alguien entregue un cambio de un fichero que usted este editando
   necesitara cotejar sus modificaciones con las de la otra u otras personas
   para poder aplicar correctamente sus modifaciones al repositorio. La forma
   mas sencilla de hacerlo es ejecutar p4 sync o p4 submit y dejar que el
   programa encuentre algun conflicto, y a continuacion ejecutar p4 resolve
   para "resolver" manualmente los conflictos y aceptar los cambios de la
   otra persona en su copia del fichero. Hecho esto, utilice p4 submit para
   aplicar sus cambios en el repositorio.

   Si posee un fichero abierto para su edicion y quiere descartar los cambios
   y devolverlo a su estado original ejecute p4 revert de la siguiente forma:

 % p4 revert nombredefichero

   Esto resincroniza el fichero con el contenido del servidor y elimina en el
   servidor el atributo de edicion para ese fichero. Se perdera cualquier
   cambio que haya hecho en local. Esto resulta muy util cuando se han
   efectuado una serie de cambios en un determinado fichero y se decide
   posteriormente que no se desean aplicar dichos cambios en el servidor.

   Cuando se sincroniza un fichero se marca como solo lectura en el sistema
   de ficheros. Aunque se pueden sobreescribir facilmente dichos permisos se
   aplican para recordar al usuario de una forma educada que para ello se
   debe utilizar p4 edit. Los ficheros modificados en local pero que no estan
   en estado de edicion pueden sobreescribirse al ejecutar p4 sync.

9. Cambios, descripciones e historial

   Puede ver el historial de cambios realizados al "deposito" de Perforce
   puede consultarse mediante p4 changes. Esta orden proporciona una breve
   descripcion de cada cambio, quien la realizo y cual es el numero de
   modificacion. Si lo que se quiere son los detalles de un cambio en
   concreto utilice p4 describe numero_de_cambio. Esta orden proporciona el
   "log" y los "diffs" de dicho cambio. Normalmente se utilizan las opciones
   -du o -dc para generar "diffs" unificados o contextuales, respectivamente,
   en lugar del formato del "diff" nativo.

   p4 filelog nombre_de_fichero muestra el historial de un fichero,
   incluyendo todas sus modificaciones, integraciones y ramas que contenga.

10. "diffs"

   Existen dos formas de generar "diffs" de ficheros en Perforce, bien entre
   cambios locales que todavia no se han entregado o bien entre dos arboles
   (o dentro de una misma rama) del "deposito". Estos "diffs" se generan
   mediante ordenes distintas, diff y diff2:

   p4 diff

           Ese comando genera un "diff" entre los cambios locales y los
           cambios de ficheros en estado de edicion. Los parametros -du y -dc
           permiten crear "diffs" unificados o contextuales, respectivamente.
           Tambien se puede establecer la variable P4DIFF para que apunte a
           un "diff" local. Le recomendamos encarecidamente usar esta orden
           para revisar sus cambios antes de aplicarlos en el servidor.

   p4 diff2

           Esta orden crea un "diffs" entre ficheros dados en el "deposito",
           o entre ficheros especificados en una especificacion de rama. La
           operacion tiene lugar en el servidor, asi que la variable P4DIFF
           no surte ningun efecto, aunque las opciones -du y -dc si pueden
           usarse. Las dos formas de esta orden son:

 % p4 diff2 -b nombrederama

           y

 % p4 diff2 //depot/ruta1 //depot/ruta2

   En todos los casos los "diffs" se muestran en la salida estandar. Por
   desgracia Perforce usa un formato de "diffs" que resulta ser ligeramente
   incompatible con las herramientas Unix estandar diff y patch. La
   utilizacion de la variable P4DIFF para que apunte al verdadero diff(1)
   puede paliar este problema, o al menos en ciertos casos, puesto solo
   funciona con la orden p4 diff. La salida de diff2 debe procesarse para que
   sea de alguna utilidad (la opcion -u de diff2 producira "diffs" unificados
   que seran mas o menos compatibles, pero no esto no incluye ficheros nuevos
   o borrados. Este "script" puede serle de utilidad para este "proceso
   necesario": http://people.freebsd.org/~scottl/awkdiff.

11. Anadir o eliminar ficheros

   La integracion de una rama hara que se anadan ficheros existentes en el
   servidor en su arbol, pero quizas sea necesario anadir nuevos ficheros o
   eliminar alguno de los ya existentes. Para anadir ficheros no tiene mas
   que crear el fichero y ejecutar p4 add de la siguiente forma:

 % p4 add nombredefichero

   Si quiere anadir un arbol completo de ficheros ejecute:

 % find . -type f |xargs p4 add

   Al ejecutar p4 submit se copiaran los ficheros al "deposito" del servidor.
   Es muy importante anadir solo ficheros y no directorios. Si se anade
   explicitamente un directorio, Perforce lo tratara como fichero, lo cual
   seguramente no es lo que usted tenia previsto.

   Borrar un fichero es igualmente sencillo mediante p4 delete:

 % p4 delete nombredefichero

   Esta orden marcara el fichero para que sea borrado del "deposito" la
   siguiente vez que se ejecute una entrega. Tambien borrara la copia local
   del fichero, asi que sea cauteloso cuando la use.

   Por supuesto que borrar un fichero no significa que se borre realmente del
   repositorio.

   Los ficheros borrados se pueden "resucitar" mediante la sincronizacion con
   una version previa. La unica forma de borrar de forma permanente un
   fichero es mediante la orden p4 obliterat. Dicha orden es irreversible y
   costosa, asi que solo esta al alcance del personal que administra el
   repositorio.

12. El trabajo con "diffs"

   Algunas veces puede ser necesario aplicar un "diff" al arbol de Perfoce
   que provenga de otra aplicacion. Si se trata de un "diff" de gran tamano y
   que afecta a muchos ficheros, puede resultar tedioso ejecutar manualmente
   p4 edit sobre cada fichero. Hay un truco para hacerlo de una forma mas
   sencilla. En primer lugar, asegurese de que no hay ficheros abiertos en su
   cliente y de que su arbol esta sincronizado y actualizado a la ultima
   version. A continuacion aplique sus cambios mediante las herramientas
   habituales, y forzando los permisos de los ficheros en caso de ser
   necesario. Despues ejecute lo siguiente:

 % p4 diff -se ... |xargs p4 edit
 % p4 diff -sd ... |xargs p4 delete
 % find . -type f |xargs p4 add

   La primera orden le dice a Perforce que busque los ficheros que han
   cambiado, incluso si no estan abiertos. La segunda orden le dice a
   Perforce que busque los ficheros que no existen en la maquina local pero
   que si estan en el servidor. La tercera orden intenta anadir todos los
   ficheros que estan en local. Es un metodo de fuerza bruta, pero funciona
   bien porque Perforce solo anadira los ficheros que le resulten
   desconocidos. El resultado de estas ordenes es un conjunto de ficheros
   abiertos para edicion, borrado o para ser anadidos, segun el caso. Hecho
   esto solo nos queda ejecutar p4 submit para entregar los cambios.

13. Cambiar nombres de ficheros

   Perforce no dispone de una forma predefinida de cambiar nombres a ficheros
   o de moverlos a otra parte del arbol. Si se copia el fichero en cuestion a
   una nueva ubicacion mediante p4 add, y posteriormente p4 delete en la
   version anterior, se obtiene algo muy parecido a lo que se queria, pero
   tiene el inconveniente de que no se preserva el historial de cambios de
   ese fichero. Esto puede perjudicar futuras integraciones entre padres e
   hijos. Hay otro metodo mas recomendable, que consiste en efectuar una
   integracion dentro del mismo arbol y de una sola vez. Veamos un ejemplo:

 % p4 integrate -i ficheroprevio ficheronuevo
 % p4 resolve
 % p4 delete ficheroprevio
 % p4 submit

   La integracion fuerza a Perforce a mantener un registro de las relaciones
   entre los nombres antiguos y los nuevos, lo cual sera muy util en futuras
   integraciones. La opcion -i indica que se trata de una integracion "sin
   base", es decir, que no existe un historial de ramas al que recurrir en la
   integracion. Este parametro tiene sentido en el presente ejemplo, pero no
   deberia utilizarse en integraciones basadas en ramas.

14. Interacciones entre el CVS de FreeBSD y Perforce

   Los repositorios de Perforce y de CVS de FreeBSD estan completamente
   separados. No obstante, los cambios que se producen en CVS se reflejan
   casi en tiempo real en Perforce. Cada 2 minutos se pregunta al servidor de
   CVS sobre cambios realizados en la rama HEAD, y dichos cambios se entregan
   a Perforce dentro del arbol //depot/vendor/freebsd/.... De este modo este
   arbol permite la ramificacion y la integracion de proyectos derivados.
   Cualquier proyecto que implique la modificacion del codigo fuente de
   FreeBSD deberia tener este arbol como su rama padre (o rama "abuela",
   dependiendo de las necesidades concretas de cada proyecto), y deberian
   tener lugar integraciones periodicas y sincronizaciones para que el arbol
   este en consonancia con el desarrollo de FreeBSD y evitar conflictos en la
   medida de lo posible.

   El puente entre CVS y Perforce es de un solo sentido; los cambios del CVS
   se reflejaran en Perforce, pero los cambios en Perforce no se reflejaran
   en el CVS. Si es necesario, se pueden exportar partes del repositorio de
   Perforce al CVSup y que asi se puedan distribuir. Por favor, contacte con
   los administradores de Perforce de FreeBSD si ese es su caso.

15. Funcionamiento sin conexion de red

   Uno de los inconvenientes de Perforce es que supone que siempre es posible
   acceder al servidor a traves de la red. La mayoria de los estados, el
   historial y los metadatos se almacenan en el servidor y no existe
   mecanismo alguno para replicar el servidor como los hay en CVS/CVSup. Es
   posible ejecutar un servidor proxy, pero solamente ayuda un poco si se
   quiere trabajar sin conexion al servidor.

   La mejor forma de trabajar sin conexion de red es comprobando que el
   cliente no tiene ningun fichero abierto y que esta totalmente sincronizado
   antes de dejar de estar conectado. Cuando se edite un fichero se deberan
   cambiar manualmente los permisos a lectura-escritura. Cuando vuelva a
   estar conectado ejecute la orden que se mostraba en la Seccion 12, "El
   trabajo con "diffs"" para identificar automaticamente los ficheros que se
   han editado, anadido o eliminado. Es bastante comun encontrarse con la
   sorpresa de que Perforce ha sobreescrito un fichero modificado en local
   que no se abrio en modo edicion, asi que tenga especial cuidado con esto.

16. Consideraciones finales para el "Google Summer of Code"

   La mayoria de los proyectos de FreeBSD dentro del programa "Google Summer
   of Code" estan en //depot/projects/soc2005/nombre_del_proyecto/... en el
   servidor FreeBSD de Perforce.

   Entre las responsabilidades del mentor del proyecto esta seleccionar un
   nombre adecuado para dicho proyecto y hacer que el estudiante sea capaz de
   trabajar con Perforce.

   El acceso al servidor FreeBSD de Perforce no implica pasar a ser miembro
   de la comunidad de committers del CVS de FreeBSD, aunque animamos de todo
   corazon a todos los estudiantes que consideren la posibilidad de unirse al
   proyecto cuando esten listos para ello.

     ----------------------------------------------------------------------

   [1] Este termino, que tambien puede traducirse como asociar o asignar,
   suele aparecer en la jerga de la administracion de sistemas como "mapear".
