           Perforce en el contexto del desarrollo de FreeBSD

  Scott Long

   <scottl@FreeBSD.org>
             

   $FreeBSD: doc/es_ES.ISO8859-1/articles/p4-primer/article.sgml,v
   1.3 2007/11/08 21:49:11 carvay Exp $

   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.

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

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

     Note: 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 Section 12 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.

  Notes

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

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

          Puede descargar este y muchos otros documentos desde
                ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Si tiene dudas sobre FreeBSD consulte la documentacion antes de escribir
                  a la lista <questions@FreeBSD.org>.
    Envie sus preguntas sobre la documentacion a <doc@FreeBSD.org>.
