os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/es_ES.ISO8859-1/articles/p4-primer/article.sgml
J. Vicente Carrasco e13f73ad67 -Add articles.ent and books.ent for easier handling of entity 
sets.

Approved by: jesusr (mentor)

-MFen:
2007-11-08 21:49:11 +00:00

986 lines
44 KiB
Text
Raw Blame History

<!--
The FreeBSD Documentation Project
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//ES">
%articles.ent;
]>
<article>
<title><application>Perforce</application> en el contexto del desarrollo de &os;</title>
<articleinfo>
<authorgroup>
<author>
<firstname>Scott</firstname>
<surname>Long</surname>
<affiliation>
<address><email>scottl@FreeBSD.org</email>
</address>
</affiliation>
</author>
</authorgroup>
<pubdate>$FreeBSD$</pubdate>
<legalnotice id="trademarks" role="trademarks">
&tm-attrib.freebsd;
&tm-attrib.cvsup;
&tm-attrib.general;
</legalnotice>
</articleinfo>
<sect1 id="intro">
<title>Introducci&oacute;n</title>
<para>El proyecto &os; utiliza el sistema de control de versiones
<application>Perforce</application> para gestionar proyectos
experimentales que todav&iacute;a no est&aacute;n listos para ser
incluidos en el repositorio principal de CVS.</para>
<sect2 id="resources">
<title>Disponibilidad, documentaci&oacute;n y recursos</title>
<para>Aunque que el producto <application>Perforce</application>
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 <application>Perforce</application>:
<ulink url="http://www.perforce.com/perforce/loadprog.html"></ulink>.
</para>
<para>Existe un cliente gr&aacute;fico, pero la mayor&iacute;a de la gente
utiliza la aplicaci&oacute;n de l&iacute;nea de &oacute;rdenes,
<command>p4</command>. Este documento trata sobre el uso de
dicha herramienta para la l&iacute;nea de &oacute;rdenes.</para>
<para>En
<ulink url="http://www.perforce.com/perforce/technical.html"></ulink>
encontrar&aacute; documentaci&oacute;n <quote>online</quote>
detallada.</para>
<para>Se recomienda encarecidamente leer la <quote>gu&iacute;a de
usuario</quote> y el <quote>manual de Perforce</quote>.
La aplicaci&oacute;n <application>p4</application> dispone de una extensa
ayuda <quote>online</quote> a la que puede accederse mediante la
orden <command>p4 help</command>.</para>
<para>El servidor &os; <application>Perforce</application> se
encuentra en
<hostid role="fqdn">perforce.freebsd.org</hostid>,
puerto <literal>1666</literal>. Puede navegar por el
repositorio desde
<ulink url="http://perforce.freebsd.org"></ulink>.
Ciertas partes del repositorio se exportan autom&aacute;ticamente hacia
diversos servidores <application>CVSup</application>.</para>
</sect2>
</sect1>
<sect1 id="start">
<title>Los comienzos</title>
<para>El primer paso para utilizar
<application>Perforce</application> consiste en obtener una cuenta
en el servidor. Si ya dispone de una cuenta en
<hostid
role="domainname">FreeBSD.org</hostid>
entre en
<hostid
role="hostname">freefall</hostid>
y ejecute el siguiente comando utilizando una contrase&ntilde;a distinta
del acceso de su &os; o de cualquier otro mecanismo de
autenticaci&oacute;n SSH:</para>
<screen>&prompt.user; <userinput>/usr/local/bin/p4newuser</userinput></screen>
<para>Por supuesto si no tiene una cuenta en
<hostid
role="domainname">FreeBSD.org</hostid>
necesitar&aacute; coordinarse con su mentor.</para>
<para>El siguiente paso consiste en establecer las variables de
entorno que necesita <command>p4</command> y en verificar
que puede conectarse al servidor. Es necesario especificar la variable
<envar>P4PORT</envar> para realizar cualquier operaci&oacute;n. Dicha
variable indica el servidor <application>Perforce</application>
con el que se va a trabajar. En el caso del Proyecto &os;, cr&eacute;ela
con el siguiente valor:</para>
<screen>&prompt.user; <userinput>export P4PORT=perforce.freebsd.org:1666</userinput></screen>
<note>
<para>Los usuarios con acceso <quote>shell</quote> al
<quote>cluster</quote>
<hostid
role="domainname">FreeBSD.org</hostid>
pueden querer encapsular el protocolo cliente-servidor de
<application>Perforce</application> a trav&eacute;s de un
t&uacute;nel SSH, en cuyo caso la variable de arriba
deber&iacute;a establecerse al valor
<literal>localhost</literal>.</para>
</note>
<para>El servidor &os; tambi&eacute;n necesita que se establezcan las
variables <envar>P4PASSWD</envar> y <envar>P4USER</envar>. Utilice
el nombre de usuario y la contrase&ntilde;a anteriores del siguiente
modo:</para>
<screen>&prompt.user; <userinput>export P4USER=<replaceable>nombre_de_usuario</replaceable></userinput>
&prompt.user; <userinput>export P4PASSWD=<replaceable>contrase&ntilde;a</replaceable></userinput></screen>
<para>Compruebe que todo funciona mediante la siguiente
orden:</para>
<screen>&prompt.user; <userinput>p4 info</userinput></screen>
<para>A resultas de esta orden deber&iacute;a ver informaci&oacute;n
referente al servidor. Si no es as&iacute; compruebe que
la variable <envar>P4PORT</envar> tiene el valor correcto.
</para>
</sect1>
<sect1 id="clients">
<title>Clientes</title>
<para>El sistema <application>Perforce</application> proporciona
acceso al repositorio y mantiene el estado del cliente de forma
individualizada. En t&eacute;rminos de
<application>Perforce</application>, un cliente es una
especificaci&oacute;n que asocia
<footnote><para>
Este t&eacute;rmino, que tambi&eacute;n puede traducirse como
asociar o asignar, suele aparecer en la jerga de la
administraci&oacute;n de sistemas como
<quote>mapear</quote>.
</para></footnote>
ficheros y directorios desde el
repositorio hasta la m&aacute;quina 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 s&iacute;).
El cliente tambi&eacute;n especifica el directorio ra&iacute;z del
&aacute;rbol de
directorios sobre el que se realiza la asociaci&oacute;n y la
m&aacute;quina
donde efectivamente est&aacute; dicho &aacute;rbol. Es por esto que
si pretende trabajar en varias m&aacute;quinas tendr&aacute; que
usar varios clientes.
</para>
<para>Puede acceder a los clientes mediante
<command>p4 client</command>. 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
continuaci&oacute;n:</para>
<variablelist>
<varlistentry>
<term><literal>Client:</literal></term>
<listitem>
<para>Este es el nombre de la especificaci&oacute;n del cliente.
Puede ser cualquier cosa, pero debe ser una cadena &uacute;nica
dentro del servidor <application>Perforce</application>. Suelen
usarse nombres como
<literal><replaceable>nombre_de_usuario</replaceable>_<replaceable>nombre_de_m&aacute;quina</replaceable></literal>,
que permite identificar f&aacute;cilmente a los clientes cuando se
navega por ellos.
Por defecto hay ya un nombre, que se
corresponde con el nombre de la m&aacute;quina.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>Description:</literal></term>
<listitem>
<para>Este campo suele consistir en un breve texto descriptivo
que ayude a identificar al cliente.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>Root:</literal></term>
<listitem>
<para>Se trata del directorio local que actuar&aacute; como
directorio ra&iacute;z para todos los ficheros dentro de la
asociaci&oacute;n en el cliente.
Debe ser una localizaci&oacute;n &uacute;nica
dentro del sistema
de ficheros que no se solape con otros ficheros o clientes
<application>Perforce</application>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>Options:</literal></term>
<listitem>
<para>La mayor&iacute;a de las opciones por defecto son correctas y
v&aacute;lidas para todo el mundo, aunque suele ser recomendable
comprobar que est&eacute;n activadas las opciones
<option>compress</option> y <option>rmdir</option>
y que no tienen el prefijo <literal>no</literal>. Los
detalles de cada una de estas opciones est&aacute;n en la
documentaci&oacute;n de <application>Perforce</application>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>LineEnd:</literal></term>
<listitem>
<para>Este par&aacute;metro gestiona las conversiones CR-LF y debe
dejarse tal cual salvo que sus necesidades espec&iacute;ficas
requieran cambiarlo.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>View:</literal></term>
<listitem>
<para>Aqu&iacute; es donde est&aacute;n las asociaciones de ficheros
servidor-a-local.
El valor por defecto es:</para>
<programlisting>//depot/... //<replaceable>cliente</replaceable>/...</programlisting>
<para>Esto asociar&aacute; por completo el repositorio
<application>Perforce</application> al directorio
<filename role="directory">Root</filename>
del cliente. <emphasis>NO USE ESTE VALOR POR DEFECTO</emphasis>.
El repositorio de &os; es enorme e intentar asociarlo y
sincronizarse con dicho repositorio tardar&aacute; much&iacute;simo y
consumir&aacute; enormes recursos. Asocie
s&oacute;lamente la secci&oacute;n del repositorio en la que va a
trabajar. Por ejemplo, hay un &aacute;rbol para el proyecto
smpng en <filename
role="directory">//depot/projects/smpng</filename>. Una
asociaci&oacute;n en ese caso ser&iacute;a algo as&iacute;:</para>
<programlisting>//depot/projects/smpng/... //<replaceable>cliente</replaceable>/...</programlisting>
<para>Los <literal>...</literal> deben tomarse literalmente
tal cual est&aacute;n. Es un dialecto de
<application>Perforce</application> para decir <quote>este
directorio y todos los ficheros y directorios por debajo de
&eacute;l.</quote>.</para>
<para>Una <quote>vista</quote> (View) puede contener m&uacute;ltiples
asociaciones. Vamos a suponer que quiere asociar los
&aacute;rboles de SMPng
y de NFS. Su <quote>View</quote> ser&iacute;a algo
as&iacute;:</para>
<programlisting>//depot/projects/smpng/... //<replaceable>cliente</replaceable>/smpng/...
//depot/projects/nfs/... //<replaceable>cliente</replaceable>/nfs/...</programlisting>
<para>Recuerde que <replaceable>cliente</replaceable> es el
nombre del cliente que se especific&oacute; en la secci&oacute;n
<literal>Client</literal>, pero en la secci&oacute;n
<literal>View</literal> adem&aacute;s se utiliza para resolver al
directorio especificado en la secci&oacute;n
<literal>Root</literal>.</para>
<para>Tambi&eacute;n tenga en cuenta que el mismo fichero o
directorio no puede asociarse m&aacute;s de una vez dentro de una
&uacute;nica vista. La orden del siguiente ejemplo no es correcta
y producir&aacute; resultados imprevistos:
</para>
<programlisting>//depot/projects/smpng/... //<replaceable>cliente</replaceable>/smpng-esto/...
//depot/projects/smpng/... //<replaceable>cliente</replaceable>/smpng-lo_otro/...</programlisting>
<para>Las <quote>vistas</quote> son la parte compleja del proceso de
aprendizaje de <application>Perforce</application>, as&iacute; que
no tenga miedo de hacer tantas preguntas como estime
oportunas.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Puede listar los clientes existentes mediante
<command>p4 clients</command>. Puede listarlos sin que sufran
modificaciones mediante <command>p4 client -o
<replaceable>nombre_cliente</replaceable></command>.
<para>Siempre que se interactue con ficheros en
<application>Perforce</application> la variable de entorno
<envar>P4CLIENT</envar> debe contener al nombre del cliente que
se est&aacute; utilizando, es decir:</para>
<screen>&prompt.user; <userinput>export P4CLIENT=<replaceable>nombredemicliente</replaceable></userinput></screen>
<para>F&iacute;jese 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
c&oacute;digo, permitiendo que distintas personas accedan y
modifiquen la misma parte del respositorio.
</para>
<sect1 id="syncing">
<title>Sincronizaciones</title>
<para>Una vez definida la especificaci&oacute;n del cliente y una vez
establecida la variable de entorno <envar>P4CLIENT</envar>, el
siguiente paso consiste en recuperar los ficheros para el cliente en
cuesti&oacute;n desde el servidor hasta la m&aacute;quina local.
Esto se realiza
con <command>p4 sync</command>, el cual indica a
<application>Perforce</application> que sincronice los ficheros
locales con los del repositorio. La primera vez que se ejecuta
descargar&aacute; todos los ficheros. Las siguientes ejecuciones
s&oacute;lo descargar&aacute;n aquellos ficheros que hayan cambiado
desde la &uacute;ltima ejecuci&oacute;n de la orden.
Gracias a esto es posible sincronizar sus fuentes con
las de otras personas con las que est&eacute; trabajando.</para>
<para>Las operaciones de sincronizaci&oacute;n s&oacute;lo
ata&ntilde;en a aquellos ficheros cuyas modificaciones han
sido transmitidas a <application>Perforce</application>.
Si se modifica o borra un fichero en local sin informar de ello
al servidor la ejecuci&oacute;n de un
<quote>sync</quote> no reflejar&aacute; dichos cambios. No obstante, la
ejecuci&oacute;n de <command>p4 sync -f</command> sincrozar&aacute;
incondicionalmente todos los ficheros, sin que importe su estado.
Esto resulta &uacute;til para solucionar problemas cuando se cree que el
&aacute;rbol pueda haber sufrido alg&uacute;n tipo de
corrupci&oacute;n.</para>
<para>Puede sincronizarse parte del &aacute;rbol o del cliente
especificando una ruta relativa a la orden <quote>sync</quote>.
Por ejemplo, para sincronizar s&oacute;lo el directorio
<filename role="directory">ufs</filename>
del proyecto <literal>smpng</literal> ejecute lo
siguiente:</para>
<screen>&prompt.user; <userinput>cd <replaceable>raizdelproyecto</replaceable>/smpng</userinput>
&prompt.user; <userinput>p4 sync src/sys/ufs/...</userinput></screen>
<para>El uso de rutas locales relativas funciona en muchas otras
&oacute;rdenes <command>p4</command>.</para>
<sect1 id="branches">
<title>Ramas</title>
<para>Una de las caracter&iacute;sticas m&aacute;s interesantes de
<application>Perforce</application> es la posibilidad de crear
ramas. Las ramas son muy sencillas de crear y tambi&eacute;n resulta muy
f&aacute;cil mover cambios entre distintas ramas (como se ver&aacute;
m&aacute;s
adelante). Las ramas tambi&eacute;n nos permiten realizar trabajos muy
experimentales dentro de un entorno de <quote>sandbox</quote>, sin
necesidad de tener que preocuparnos por las colisiones con otros
usuarios o por desestabilizar el &aacute;rbol principal. Adem&aacute;s,
las ramas
proporcionan el aislamiento necesario frente a los errores que se
cometen cuando se aprende a manejar el sistema
<application>Perforce</application>. Vistas estas ventajas es
l&oacute;gico que cada proyecto disponga de su propia rama y
en &os; recomendamos encarecidamente este esquema.
Tambi&eacute;n se recomienda la aplicaci&oacute;n frecuente de los cambios
realizados.</para>
<para>El repositorio <application>Perforce</application> (conocido
como el <quote>dep&oacute;sito</quote>, o <quote>depot</quote> en
la jerga de <application>Perforce</application>)
es un &uacute;nico &aacute;rbol plano. Se accede a cada fichero a
trav&eacute;s de una
sencilla ruta bajo el directorio <filename
role="directory">//depot</filename>, tanto si se trata de un
fichero de nueva creaci&oacute;n como si proviene de una
ramificaci&oacute;n.
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 <application>Perforce</application> el servidor mantiene las
relaciones entre los ficheros padre e hijo, pero los
ficheros en s&iacute; est&aacute;n bajo sus propias rutas.</para>
<para>El primer para para crear una rama consiste en crear una
especificaci&oacute;n de rama. Es similar a la especificaci&oacute;n
de un cliente,
pero se crea mediante la orden <command>p4 branch
<replaceable>nombre_de_rama</replaceable></command>.</para>
<para>Veamos los campos m&aacute;s importantes:</para>
<variablelist>
<varlistentry>
<term><literal>Branch</literal></term>
<listitem>
<para>El nombre de la rama. Puede ser cualquier nombre, pero
debe ser &uacute;nico en el repositorio. La convenci&oacute;n
que se usa en &os; es
<replaceable>nombre_de_usuario</replaceable>_<replaceable>nombre_del_proyecto</replaceable>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>Description</literal></term>
<listitem>
<para>Puede poner aqu&iacute; un texto simple que describa la
rama.
</listitem>
</varlistentry>
<varlistentry>
<term><literal>View</literal></term>
<listitem>
<para>Esto es la asociaci&oacute;n de la rama. En lugar de asociar
desde el <quote>dep&oacute;sito</quote> hacia la m&aacute;quina local
como una asociaci&oacute;n de cliente, se crea una asociaci&oacute;n
entre la rama padre y la rama hija
dentro del <quote>dep&oacute;sito</quote>. Por ejemplo, puede
querer crear una rama del proyecto smpng. La asociaci&oacute;n
resultar&iacute;a en algo parecido a esto:</para>
<programlisting>//depot/projects/smpng/... //depot/projects/mi-super-smpng/...</programlisting>
<para>O puede crear una rama totalmente nueva a
partir de las fuentes de &os;:</para>
<programlisting>//depot/vendor/freebsd/... //depot/projects/mi-nuevo-proyecto/...</programlisting>
<para>Esto asociar&aacute; el HEAD del &aacute;rbol de &os; a su
nueva rama.</para>
</listitem>
</varlistentry>
</variablelist>
<para>La creaci&oacute;n de la especificaci&oacute;n de rama
&uacute;nicamente graba la
especificaci&oacute;n en s&iacute; misma dentro del servidor. No
modifica el <quote>dep&oacute;sito</quote> ni cambia
ning&uacute;n fichero. El directorio que se declara en la rama
permanece vac&iacute;o en el servidor hasta que se comience a
llenar.
</para>
<para>Para rellenar la rama primero debemos editar el cliente con
la orden <command>p4 client</command> y asegurarnos de que el
directorio de rama est&aacute; asociado en el cliente. Puede ser
necesario a&ntilde;adir una l&iacute;nea <literal>View</literal>
como esta:</para>
<programlisting>//depot/projects/mi-nuevo-proyecto/... //<replaceable>micliente</replaceable>/mi-nuevo-proyecto/...</programlisting>
<para>El siguiente paso consiste en ejecutar <command>p4
integrate</command>, como se describe en la siguiente
secci&oacute;n.</para>
<sect1 id="Integrations">
<title>Integraciones</title>
<para><quote>Integraci&oacute;n</quote> es el t&eacute;rmino que se utiliza
en <application>Perforce</application> para describir la acci&oacute;n de
mover cambios desde una parte del <quote>dep&oacute;sito</quote> a otra.
Se suele realizar junto con las &oacute;rdenes creaci&oacute;n y
mantenimiento de ramas. Una integraci&oacute;n 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 com&uacute;n es la integraci&oacute;n
peri&oacute;dica desde el &aacute;rbol original de &os; hacia la rama
hija propia del usuario.
El servidor <application>Perforce</application>
mantiene el estado de los cambios en cada rama y sabe cu&aacute;ndo
hay cambios que pueden integrarse de una rama a otra.</para>
<para>La forma m&aacute;s com&uacute;n de hacer una integraci&oacute;n
se muestra en la siguiente orden:
</para>
<screen>&prompt.user; <userinput>p4 integrate -b <replaceable>nombrederama</replaceable></userinput></screen>
<para><replaceable>nombrederama</replaceable> es el nombre que se
ha dado a la
especificaci&oacute;n de rama, tal y como se explic&oacute; en la
secci&oacute;n anterior.
Esta orden indica a <application>Perforce</application> que
busque cambios en la rama padre que todav&iacute;a no se hayan
aplicado a la rama hija. En base a los cambios encontrados se
prepara un listado de diferencias a aplicar. Si la integraci&oacute;n
se realiza por primera vez sobre una rama (por ejemplo cuando se
realiza una operaci&oacute;n de rellenado inicial) los ficheros
de la rama padre simplemente se copiar&aacute;n en la ubicaci&oacute;n
en la rama hija de la m&aacute;quina local.</para>
<para>Una vez que la operaci&oacute;n de integraci&oacute;n ha finalizado
se debe ejecutar <command>p4 resolve</command>, que aplicar&aacute;
los cambios y resolver&aacute; 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 <application>Perforce</application>
puede calcular r&aacute;pidamente c&oacute;mo unir los cambios.
Para ejecutar una operaci&oacute;n de resoluci&oacute;n
(<quote>resolve</quote>) utilice las siguientes &oacute;rdenes:</para>
<screen>&prompt.user; <userinput>p4 resolve -as</userinput>
&prompt.user; <userinput>p4 resolve</userinput></screen>
<para>La primera invocaci&oacute;n indica a
<application>Perforce</application> que una autom&aacute;ticamente los
cambios y que acepte aquellos ficheros que no den conflictos. La
segunda invocaci&oacute;n permite inspeccionar cada fichero con conflictos
y resolver de forma manual dichas incompatiblidades.</para>
<para>Una vez hecha la integraci&oacute;n de los ficheros llega el
momento de aplicar los cambios al repositorio. Para ello se
emplearemos la orden
<command>p4 submit</command>, cuyo uso se explica en la
siguiente secci&oacute;n.</para>
</sect1>
<sect1 id="submit">
<title>Aplicaci&oacute;n de cambios en el repositorio</title>
<para>Los cambios que se han realizado en local se deben
aplicar en el contenido del servidor <application>Perforce</application>
para mayor seguridad frente a p&eacute;rdidas y para que otras
personas puedan acceder a dichos cambios; esto se hace con la
orden <command>p4 submit</command>. Cuando se ejecuta esta
orden se abre una plantilla (<quote>submit template</quote>)
en el editor. &os; dispone de una platilla personalizada, de la
que a continuaci&oacute;n se explican los campos m&aacute;s
importantes:</para>
<programlisting>Description:
&lt;enter description here&gt;
PR:
Submitted by:
Reviewed by:
Approved by:
Obtained from:
MFP4 after:</programlisting>
<para>es decir</para>
<programlisting>Descripci&oacute;n:
&lt;Introduzca una descripci&oacute;n&gt;
PR:
Enviado por:
Revisado por:
Aprobado por:
Obtenido de:
MFP4 tras:</programlisting>
<para>Se considera una buena pr&aacute;ctica proporcionar al menos dos o
tres frases que describan los cambios entregados. Deber&iacute;a
declarar aqu&iacute; qu&eacute; hacen dichos cambios, por qu&eacute;
se han hecho de esa forma o qu&eacute; problemas intenta resolver
con ellos. Tambi&eacute;n
conviene explicar qu&eacute; APIs cambian y qu&eacute; otros efectos
secundarios pueden tener.
Este texto debe sustituir a la l&iacute;nea <literal>&lt;enter
description here&gt;</literal> que aparece en la plantilla. Debe
recubrir las l&iacute;neas y comenzar cada l&iacute;nea con una
tabulaci&oacute;n. Las etiquetas de m&aacute;s abajo son
espec&iacute;ficas de &os; y puede eliminarlas si no resultan
&uacute;tiles o apropiadas en su contexto.</para>
<programlisting>Files:</programlisting>
<para>Este campo se rellena autom&aacute;ticamente con todos los ficheros
que el cliente etiquet&oacute; en el servidor con estados de
adici&oacute;n, borrado, integraci&oacute;n o edici&oacute;n.
Le aconsejamos que revise esta lista y elimine de ella los ficheros
que todav&iacute;a no esten listos.</para>
<para>Una vez guardada la sesi&oacute;n de su editor tiene lugar la entrega
de los datos al servidor. Esto significa que las copias locales de
los ficheros entregados se enviar&aacute;n al servidor. Si algo va
mal durante este proceso se cancelar&aacute; la entrega y se
avisar&aacute; al usuario de que la entrega se ha convertido en
una lista de cambios que deben corregirse y reenviarse. Las
entregas son at&oacute;micas, es decir, si un fichero falla
la entrega se cancela en su totalidad.</para>
<para>Los cambios efectuados en el servidor no pueden cancelarse
una vez hechos, pero s&iacute; que pueden cancelarse si, dentro
a&uacute;n del editor, se sale de &eacute;l sin cambiar el
texto del campo
<literal>Description</literal>. <application>Perforce</application>
se quejar&aacute; la primera vez que intente salir y le
devolver&aacute; al editor. Si sale por segunda vez el editor
cancelar&aacute; la operaci&oacute;n. Devolver el repositorio
al estado anterior a un cambio ya efectuado es un proceso
muy complicado y no hay un procedimiento est&aacute;ndar, por lo
que depende del caso concreto.</para>
</sect1>
<sect1 id="editing">
<title>Edici&oacute;n</title>
<para>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
<application>Perforce</application> presta atenci&oacute;n a qu&eacute;
ficheros est&aacute;n abiertos en modo de edici&oacute;n, y utiliza
esa informaci&oacute;n para poder gestionar posteriormente las
operaciones de entrega, las sincronizaciones y las
integraciones.</para>
<para>Para abrir un fichero para editarlo utilice <command>p4
edit</command> de la siguiente forma:</para>
<screen>&prompt.user; <userinput>p4 edit <replaceable>nombredefichero</replaceable></userinput></screen>
<para>Esto marca el fichero en el servidor con el estado de
edici&oacute;n, lo que permite entregar el fichero posteriormente
una vez realizados los cambios oportunos, o lo etiqueta como de
tratamiento especial cuando se est&aacute; efectuando una
operaci&oacute;n de integraci&oacute;n o sincronizaci&oacute;n.
Tenga en cuenta que la edici&oacute;n no es exclusiva en
<application>Perforce</application>. Varias personas pueden tener
el mismo fichero en estado de edici&oacute;n (ser&aacute;
informado de ello si es necesario cuando ejecute
<command>edit</command>), pero podr&aacute; entregar sus cambios
incluso cuando haya otras personas que tengan ese fichero en estado
de edici&oacute;n.</para>
<para>Cuando alguien entregue un cambio de un fichero que usted
est&eacute; editando necesitar&aacute; cotejar sus modificaciones
con las de la otra u otras personas para poder aplicar
correctamente sus modifaciones al repositorio. La forma m&aacute;s
sencilla de hacerlo es ejecutar
<command>p4 sync</command> o <command>p4 submit</command> y dejar
que el programa encuentre alg&uacute;n conflicto, y a
continuaci&oacute;n
ejecutar <command>p4 resolve</command> para <quote>resolver</quote>
manualmente los conflictos y aceptar los cambios de la otra persona
en su copia del fichero. Hecho esto, utilice <command>p4
submit</command> para aplicar sus cambios en el
repositorio.</para>
<para>Si posee un fichero abierto para su edici&oacute;n y
quiere descartar los cambios y devolverlo a su estado
original ejecute
<command>p4 revert</command> de la siguiente forma:</para>
<screen>&prompt.user; <userinput>p4 revert <replaceable>nombredefichero</replaceable></userinput></screen>
<para>Esto resincroniza el fichero con el contenido del servidor y
elimina en el servidor el atributo de edici&oacute;n para ese fichero.
Se perder&aacute; cualquier cambio que haya hecho en local.
Esto resulta muy &uacute;til 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.</para>
<para>Cuando se sincroniza un fichero se marca como s&oacute;lo lectura en
el sistema de ficheros. Aunque se pueden sobreescribir f&aacute;cilmente
dichos permisos se aplican para recordar al usuario de una forma
educada que para ello se debe utilizar <command>p4 edit</command>.
Los ficheros modificados en local pero que no est&aacute;n en
estado de edici&oacute;n pueden sobreescribirse al ejecutar
<command>p4 sync</command>.</para>
<sect1 id="changes">
<title>Cambios, descripciones e historial</title>
<para>Puede ver el historial de cambios realizados al
<quote>dep&oacute;sito</quote> de
<application>Perforce</application> puede consultarse mediante
<command>p4 changes</command>. Esta orden proporciona una breve
descripci&oacute;n de cada cambio, qui&eacute;n la realiz&oacute;
y c&uacute;al es el n&uacute;mero de
modificaci&oacute;n. Si lo que se quiere son los detalles
de un cambio en concreto utilice
<command>p4 describe
<replaceable>numero_de_cambio</replaceable></command>. Esta orden
proporciona el <quote>log</quote> y los
<quote>diffs</quote> de dicho cambio.
Normalmente se utilizan las opciones <option>-du</option> o
<option>-dc</option> para generar <quote>diffs</quote> unificados o
contextuales, respectivamente, en lugar del formato
del <quote>diff</quote> nativo.</para>
<para><command>p4 filelog <replaceable>nombre_de_fichero</replaceable></command>
muestra el historial de un fichero, incluyendo todas sus modificaciones,
integraciones y ramas que contenga.</para>
</sect1>
<sect1 id="diffs">
<title><quote>diffs</quote></title>
<para>Existen dos formas de generar <quote>diffs</quote> de ficheros en
<application>Perforce</application>, bien entre cambios locales
que todav&iacute;a no se han entregado o bien entre dos
&aacute;rboles (o dentro de una misma rama) del
<quote>dep&oacute;sito</quote>. Estos <quote>diffs</quote>
se generan mediante &oacute;rdenes distintas,
<option>diff</option> y <option>diff2</option>:</para>
<variablelist>
<varlistentry>
<term><command>p4 diff</command></term>
<listitem>
<para>Ese comando genera un <quote>diff</quote> entre los cambios
locales y los cambios de ficheros en estado de edici&oacute;n. Los
par&aacute;metros <option>-du</option> y <option>-dc</option>
permiten crear <quote>diffs</quote> unificados o contextuales,
respectivamente. Tambi&eacute;n se puede establecer la variable
<envar>P4DIFF</envar> para que apunte a un
<quote>diff</quote> local. Le recomendamos encarecidamente
usar esta orden para revisar sus cambios antes de
aplicarlos en el servidor.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command>p4 diff2</command></term>
<listitem>
<para>Esta orden crea un <quote>diffs</quote> entre ficheros
dados en el <quote>dep&oacute;sito</quote>, o entre
ficheros especificados en una especificaci&oacute;n de rama. La
operaci&oacute;n tiene lugar en el servidor, as&iacute; que
la variable <envar>P4DIFF</envar> no surte ning&uacute;n efecto,
aunque las opciones <option>-du</option> y
<option>-dc</option> s&iacute; pueden usarse. Las dos formas de
esta orden son:</para>
<screen>&prompt.user; <userinput>p4 diff2 -b <replaceable>nombrederama</replaceable></userinput></screen>
<para>y</para>
<screen>&prompt.user; <userinput>p4 diff2 //depot/<replaceable>ruta1</replaceable> //depot/<replaceable>ruta2</replaceable></userinput></screen>
</listitem>
</varlistentry>
</variablelist>
<para>En todos los casos los <quote>diffs</quote> se muestran en la salida
est&aacute;ndar. Por desgracia <application>Perforce</application>
usa un formato de <quote>diffs</quote> que resulta ser ligeramente
incompatible con las herramientas Unix est&aacute;ndar
<command>diff</command> y <command>patch</command>. La utilizaci&oacute;n
de la variable <envar>P4DIFF</envar> para que apunte al verdadero
&man.diff.1; puede paliar este problema, o al menos en ciertos casos,
puesto s&oacute;lo funciona con la orden
<command>p4 diff</command>. La salida de
<option>diff2</option> debe procesarse para que sea de alguna
utilidad (la opci&oacute;n <option>-u</option> de
<option>diff2</option> producir&aacute; <quote>diffs</quote>
unificados que ser&aacute;n <emphasis>m&aacute;s o menos
compatibles</emphasis>, pero no esto no incluye ficheros
nuevos o borrados. Este <quote>script</quote> puede serle
de utilidad para este <quote>proceso necesario</quote>:
<ulink
url="http://people.freebsd.org/~scottl/awkdiff"></ulink>.</para>
</sect1>
<sect1 id="add-rm-files">
<title>A&ntilde;adir o eliminar ficheros</title>
<para>La integraci&oacute;n de una rama har&aacute; que
se a&ntilde;adan ficheros existentes en el servidor en su
&aacute;rbol, pero quiz&aacute;s sea necesario a&ntilde;adir
nuevos ficheros o eliminar alguno de los ya existentes.
Para a&ntilde;adir ficheros no tiene m&aacute;s que
crear el fichero y ejecutar
<command>p4 add</command> de la siguiente forma:</para>
<screen>&prompt.user; <userinput>p4 add <replaceable>nombredefichero</replaceable></userinput></screen>
<para>Si quiere a&ntilde;adir un &aacute;rbol completo de ficheros
ejecute:</para>
<screen>&prompt.user; <userinput>find . -type f |xargs p4 add</userinput></screen>
<para>Al ejecutar <command>p4 submit</command> se copiar&aacute;n los
ficheros al <quote>dep&oacute;sito</quote> del servidor.
Es muy importante a&ntilde;adir
s&oacute;lo ficheros y no directorios. Si se a&ntilde;ade
expl&iacute;citamente un
directorio, <application>Perforce</application> lo tratar&aacute; como
fichero, lo cual seguramente no es lo que usted ten&iacute;a
previsto.</para>
<para>Borrar un fichero es igualmente sencillo mediante
<command>p4 delete</command>:</para>
<screen>&prompt.user; <userinput>p4 delete <replaceable>nombredefichero</replaceable></userinput></screen>
<para>Esta orden marcar&aacute; el fichero para que sea borrado del
<quote>dep&oacute;sito</quote> la siguiente vez que se ejecute una
entrega.
Tambi&eacute;n borrar&aacute; la copia local del fichero, as&iacute; que
sea cauteloso cuando la use.</para>
<para>Por supuesto que borrar un fichero no significa que se borre
realmente del repositorio.</para>
<para>Los ficheros borrados se pueden <quote>resucitar</quote>
mediante la sincronizaci&oacute;n con una versi&oacute;n
previa. La &uacute;nica forma de borrar de forma permanente un
fichero es mediante la orden <command>p4 obliterat</command>.
Dicha orden es irreversible y costosa, as&iacute; que s&oacute;lo
est&aacute; al alcance del personal que administra
el repositorio.</para>
</sect1>
<sect1 id="working-with-diffs">
<title>El trabajo con <quote>diffs</quote></title>
<para>Algunas veces puede ser necesario aplicar un <quote>diff</quote>
al &aacute;rbol
de <application>Perfoce</application> que provenga de otra
aplicaci&oacute;n. Si se trata de un <quote>diff</quote>
de gran tama&ntilde;o y que afecta a muchos ficheros, puede resultar
tedioso ejecutar manualmente <command>p4 edit</command> sobre cada
fichero. Hay un truco para hacerlo de una forma m&aacute;s sencilla.
En primer lugar, aseg&uacute;rese de que no hay ficheros abiertos en su
cliente y de que su &aacute;rbol est&aacute; sincronizado y actualizado a la
&uacute;ltima versi&oacute;n. A continuaci&oacute;n aplique
sus cambios mediante las herramientas habituales, y forzando los
permisos de los ficheros en caso de ser necesario. Despu&eacute;s
ejecute lo siguiente:</para>
<screen>&prompt.user; <userinput>p4 diff -se ... |xargs p4 edit</userinput>
&prompt.user; <userinput>p4 diff -sd ... |xargs p4 delete</userinput>
&prompt.user; <userinput>find . -type f |xargs p4 add</userinput></screen>
<para>La primera orden le dice a
<application>Perforce</application> que busque los ficheros que
han cambiado, incluso si no est&aacute;n abiertos. La segunda
orden le dice a <application>Perforce</application> que busque
los ficheros que no existen en la m&aacute;quina local pero que
s&iacute; est&aacute;n en el servidor. La tercera orden intenta
a&ntilde;adir todos los ficheros que est&aacute;n en local. Es
un m&eacute;todo de fuerza bruta, pero funciona bien porque
<application>Perforce</application> s&oacute;lo a&ntilde;adir&aacute;
los ficheros que le resulten desconocidos. El resultado de estas
&oacute;rdenes es un conjunto de ficheros abiertos para edici&oacute;n,
borrado o para ser a&ntilde;adidos, seg&uacute;n el caso. Hecho
esto solo nos queda ejecutar
<command>p4 submit</command> para entregar los cambios.</para>
</sect1>
<sect1 id="renaming-files">
<title>Cambiar nombres de ficheros</title>
<para><application>Perforce</application> no dispone de una forma
predefinida de cambiar nombres a ficheros o de moverlos a otra parte
del &aacute;rbol. Si se copia el fichero en
cuesti&oacute;n a una nueva ubicaci&oacute;n mediante <command>p4
add</command>, y posteriormente <command>p4
delete</command> en la versi&oacute;n anterior, se obtiene
algo muy parecido a lo que se quer&iacute;a, 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 m&eacute;todo m&aacute;s recomendable,
que consiste en efectuar una integraci&oacute;n dentro del
mismo &aacute;rbol y de una sola vez. Veamos un ejemplo:</para>
<screen>&prompt.user; <userinput>p4 integrate -i <replaceable>ficheroprevio</replaceable> <replaceable>ficheronuevo</replaceable></userinput>
&prompt.user; <userinput>p4 resolve</userinput>
&prompt.user; <userinput>p4 delete <replaceable>ficheroprevio</replaceable></userinput>
&prompt.user; <userinput>p4 submit</userinput></screen>
<para>La integraci&oacute;n fuerza a <application>Perforce</application> a
mantener un registro de las relaciones entre los nombres antiguos y
los nuevos, lo cual ser&aacute; muy &uacute;til en futuras
integraciones. La opci&oacute;n
<option>-i</option> indica que se trata de una integraci&oacute;n
<quote>sin base</quote>, es decir, que no existe un historial de
ramas al que recurrir en la integraci&oacute;n. Este
par&aacute;metro tiene sentido en el presente ejemplo, pero
no deber&iacute;a utilizarse en integraciones basadas en ramas.</para>
<sect1 id="freebsd-cvs-and-p4">
<title>Interacciones entre el CVS de &os; y Perforce</title>
<para>Los repositorios de
<application>Perforce</application> y de CVS de &os; est&aacute;n
completamente separados. No obstante, los cambios que se producen
en CVS se reflejan casi en tiempo real en
<application>Perforce</application>. Cada 2 minutos se pregunta al
servidor de CVS sobre cambios realizados en la rama HEAD, y dichos
cambios se entregan a <application>Perforce</application> dentro del
&aacute;rbol <filename
role="directory">//depot/vendor/freebsd/...</filename>.
De este modo este &aacute;rbol permite la ramificaci&oacute;n y
la integraci&oacute;n de proyectos derivados. Cualquier proyecto
que implique la modificaci&oacute;n del c&oacute;digo fuente de
&os; deber&iacute;a tener este &aacute;rbol como su rama padre
(o rama <quote>abuela</quote>, dependiendo
de las necesidades concretas de cada proyecto), y deber&iacute;an tener
lugar integraciones peri&oacute;dicas y sincronizaciones para que el
&aacute;rbol est&eacute; en consonancia con el desarrollo de &os; y
evitar conflictos en la medida de lo posible.</para>
<para>El puente entre CVS y <application>Perforce</application> es
de un s&oacute;lo sentido; los cambios del CVS se reflejar&aacute;n en
<application>Perforce</application>, pero los cambios en
<application>Perforce</application> no se reflejar&aacute;n en el CVS.
Si es necesario, se pueden exportar partes del repositorio de
<application>Perforce</application> al
<application>CVSup</application> y que as&iacute; se puedan distribuir.
Por favor, contacte con los
administradores de <application>Perforce</application> de &os; si
ese es su caso.</para>
</sect1>
<sect1 id="offline-ops">
<title>Funcionamiento sin conexi&oacute;n de red</title>
<para>Uno de los inconvenientes de <application>Perforce</application> es
que supone que siempre es posible acceder al servidor a trav&eacute;s
de la red. La mayor&iacute;a 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/<application>CVSup</application>. Es posible
ejecutar un servidor proxy, pero solamente ayuda un poco si se quiere
trabajar sin conexi&oacute;n al servidor.</para>
<para>La mejor forma de trabajar sin conexi&oacute;n de red es
comprobando que el cliente no tiene ning&uacute;n fichero abierto y
que est&aacute; totalmente sincronizado antes de dejar de estar
conectado.
Cuando se edite un fichero se deber&aacute;n cambiar manualmente
los permisos a lectura-escritura. Cuando vuelva a estar
conectado ejecute la orden que se mostraba
en la <xref linkend="working-with-diffs"> para
identificar autom&aacute;ticamente los ficheros que se han editado,
a&ntilde;adido o eliminado.
Es bastante com&uacute;n encontrarse con la sorpresa de que
<application>Perforce</application> ha sobreescrito un fichero
modificado en local que no se abri&oacute; en modo edici&oacute;n,
as&iacute; que tenga especial cuidado con esto.</para>
</sect1>
<sect1 id="soc">
<title>Consideraciones finales para el <quote>Google Summer of Code</quote></title>
<para>La mayor&iacute;a de los proyectos de &os; dentro del programa
<quote>Google Summer of Code</quote> est&aacute;n en
<filename
role="directory">//depot/projects/soc2005/<replaceable>nombre_del_proyecto</replaceable>/...</filename>
en el servidor &os; de <application>Perforce</application>.</para>
<para>Entre las responsabilidades del mentor del proyecto
est&aacute; seleccionar un nombre adecuado para dicho proyecto y
hacer que el estudiante sea capaz de trabajar con
<application>Perforce</application>.</para>
<para>El acceso al servidor &os; de
<application>Perforce</application> no implica pasar a ser miembro
de la comunidad de committers del CVS de &os;, aunque animamos
de todo coraz&oacute;n a todos los estudiantes que consideren la
posibilidad de unirse al proyecto cuando est&eacute;n listos
para ello.</para>
</sect1>
</article>
Reference in a new issue View git blame Copy permalink