diff --git a/es_ES.ISO8859-1/articles/Makefile b/es_ES.ISO8859-1/articles/Makefile index fc51de7659..a406232673 100644 --- a/es_ES.ISO8859-1/articles/Makefile +++ b/es_ES.ISO8859-1/articles/Makefile @@ -1,19 +1,21 @@ # $FreeBSD$ # $FreeBSDes: doc/es_ES.ISO8859-1/articles/Makefile,v 1.3 2004/10/09 02:01:17 jesusr Exp $ SUBDIR = +SUBDIR+= casestudy-argentina.com SUBDIR+= contributing SUBDIR+= cvs-freebsd SUBDIR+= dialup-firewall SUBDIR+= euro SUBDIR+= explaining-bsd SUBDIR+= fbsd-from-scratch SUBDIR+= laptop SUBDIR+= mailing-list-faq +SUBDIR+= p4-primer SUBDIR+= problem-reports SUBDIR+= releng SUBDIR+= zip-drive DOC_PREFIX?= ${.CURDIR}/../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/es_ES.ISO8859-1/articles/casestudy-argentina.com/Makefile b/es_ES.ISO8859-1/articles/casestudy-argentina.com/Makefile new file mode 100644 index 0000000000..643e6d8249 --- /dev/null +++ b/es_ES.ISO8859-1/articles/casestudy-argentina.com/Makefile @@ -0,0 +1,19 @@ +# +# $FreeBSD$ +# +# Articulo: Estudio de caso de Argentina.com + +DOC?= article + +FORMATS?= html +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.sgml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml b/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml new file mode 100644 index 0000000000..a403a76c34 --- /dev/null +++ b/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml @@ -0,0 +1,417 @@ +$FreeBSD$ + + + + + + +%man; + %freebsd; + %newsgroups; + +%authors; + +%trademarks; + +%translators; + %mailing-lists; + +]> + + +
+ Argentina.com : Un estudio de caso + + + + + Carlos + Horowicz + +
ch@argentina.com +
+ + + + + $FreeBSD$ + + + &tm-attrib.freebsd; + &tm-attrib.cvsup; + &tm-attrib.intel; + &tm-attrib.xfree86; + &tm-attrib.general; + + + + + + Introducción + + Argentina.Com es un ISP argentino con una pequeña + infraestructura de menos de 15 empleados y cuya fuente principal de + ingresos proviene del negocio del acceso telefónico a redes + gratuito. Comenzó a operar en el año 2000 con sólo + un servidor para correo y chat. + + Desde entonces ha crecido su presencia en un mercado + argentino de acceso telefónico a redes que genera unos 45.000 + millones de minutos anualmente. Su producto más famoso proporciona + a cerca de medio millón de usuarios correo gratuito con webmail, + POP3 y acceso SMPT, junto con 300M de espacio de disco. Hacia el + final de 2002 había alrededor de 50.000 usuarios de correo. + Después de dos años y medio de reingeniería y de + sólidas mejoras + técnicas este ISP ha crecido en un factor de 3 en términos + de facturación, y en un factor de 10 en cuanto a la base de usuarios + de correo. + + Nuestros competidores en el mercado argentino de acceso + telefónico incluyen a Fullzero (filial perteneciente a Clarin + Media Group), + Alternativa Gratis y Tutopia, este último fundado por IFX y + promocionado por Hotmail. Algunos de estos grandes competidores + comenzaron sus respectivos negocios de acceso telefónico con + inversiones multimillonarias y con campañas de publicidad agresivas + en televisión e Internet. Argentina.Com no utiliza este tipo de + publicidad. Ha alcanzado la cuarta posición con un 8% de cuota de + mercado durante los dos últimos años gracias a un calidad de + servicio superior. + + En Argentina y en Latinoamérica en general las personas que + no poseen ordenador personal van a los llamados + locutorios (centros de Internet), donde por unos + pocos pesos pueden utilizar un ordenador conectado a Internet y + donde normalmente leen y escriben correos electrónicos a + través de portales + populares como Hotmail, Yahoo! o Argentina.Com. + + Debido a los limitados recursos financieros disponibles, + Argentina.Com decidió invertir en un nuevo sistema de correo en vez + de darse publicidad a través de los medios. Esta decisión + estratégica abre las puertas a un futuro negocio en el campo del + correo corporativo y de pago. + + + + El desafío + + El desafío principal para Argentina.Com es alcanzar un tiempo + de vida para el servicio de acceso telefónico a redes de al menos + 99.95%, o menos de 5 horas de caídas al año. Debido a la alta + rotación y volatilidad que existe en este negocio, las cosas deben + funcionar correctamente para que el usuario no cambie + -voluntariamente o no- de proveedor de acceso a internet o de número + de teléfono utilizado para conectarse. El negocio del + dialup, como se le conoce en su denominación inglesa, + requiere una estructura de soporte para tratar con las grandes + operadoras de telecomunicaciones problemas telefónicos y de + calidad de servicio, junto con una infraestructura técnica donde la + latencia y la pérdida de paquetes deben minimizarse debido a la + naturaleza UDP de los servicio de Radius y DNS, y donde el DNS + recursivo debería estar siempre disponible. + + Esto tambíen implica tener un tiempo de vida alto en los + servicio de POP3 y SMTP, junto con el servicio de webmail. Para + POP3 y SMTP se estimó la necesidad de uptime igual + que para el servicio de dialup, mientras que para el + servicio de webmail se pensó en un porcentaje de 99.5%, lo que + significa alrededor de dos dias por año sin servicio o de + caída. + + Decidimos migrar el correo a una solución propietaria de + código abierto que debería ser horizontalmente escalable y cuyos + sistemas antivirus y antispam pudieran soportar más de un + único tipo + de backend o de almacenamiento de correos. + + La feroz competencia en el mercado del correo + electrónico gratuito, principalmente iniciada por las recientes + mejoras introducidas por Hotmail, Yahoo! y Gmail, hacían necesario + diseñar el nuevo sistema con al menos 300M de espacio de usuario en + disco para cada usuario, pero a un coste inferior a 3 dólares + americanos por GB incluyendo cierto grado de redundancia. Hay que tener + en cuenta que el hardware que puede disponerse en rack + es difícil de encontrar en Argentina y que + resulta ser entre un 30 y un 40% más caro que en los EEUU. Nuestro + líquido financiero para adquisición de equipos en dos + años fue de + 75.000 dólares americanos, lo cual es una fracción muy + pequeña de las + inversiones acometidas por nuestros competidores directos. + + Respecto al servicio antispam, era necesario desarrollar un + producto que pudiera competir con los sistemas ofrecidos por los + grandes. Dadas las hostiles condiciones que impone la existencia del + spam (ataques de diccionario, spams con alto grado de ofuscación y + refinamiento, phishing, troyanos, correos-bomba, + etc.) resulta muy complicado alcanzar tiempos de uptime + excelentes y + al mismo tiempo repeler dichos ataques. Uno debe también ser + cuidadoso para que el usuario no pierda correos debido a falsos + positivos en la estrategia de clasificación, para que no se le + inunde con spam o notificaciones de spam y para que el correo + peligroso no alcance la carpeta de entrada de los usuarios. Por + último, el sistema de correo debe protegerse para que los + spammers no lo utilicen en su provecho para + enviar spam. + + El paradigma del código abierto normalmente requiere la + adquisición de grandes equipos de administradores de sistemas, + operadores y programadores que se encarguen de aplicar parches, + corregir bugs e integrar plataformas. El paradigma opuesto es + también costoso debido a las caras licencias de software, la + necesidad de hardware cada vez más caro y debido al + elevado número de empleados encargados de proporcionar soporte. + Así que el desafío era + encontrar la mezcla correcta entre recursos monetarios y humanos + escasos, alta estabilidad y grado de predicción, y un desarrollo + rápido y fiable. En Buenos Aires resulta difícil encontrar + profesionales de las ciencias de la computación bien entrenados, la + mayoría de los cuales viven y trabajan en el extranjero, mientras + que los restantes poseen trabajos estables dentro de las + instituciones del gobierno o en grades compañías. + + + + La solución FreeBSD + + + Introducción + + A comienzos de 2003 teníamos un sistema de correo + CriticalPath bajo Solaris x86 y una máquina Redhat + para SMTP, Radius y DNS. Los servicios de DNS y Radius se caían + constantemente y estábamos luchando con colas enormes de correo + electrónico. Hubo un intento de instalar CriticalPath para Linux + en Redhat en una máquina Intel con una tarjeta Megaraid, pero la + latencia del disco era enorme y la aplicación de correo + no llegó a funcionar. + + El primer paso realizado hacia la solución &os; + consitió en migrar este hardware y software comercial a &os; + 4.8 con la ayuda de la emulación Linux. + + + + La elección de &os; + + El sistema operativo &os; goza de una merecida fama de por su gran + estabilidad, junto con su pragmatismo y sentido común a la hora de + poner aplicaciones on-line gracias a su excelente + colección de Ports. + Nosotros consideramos su + proceso de generación de releases muy sencillo de entender, + además de que la comunidad de usuarios de las listas oficiales + de correo electrónico mantiene un estilo educado y civilizado + cuando ayudan o leen los problemas de otros usuarios y sus soluciones. + + + Otra característica importante es su rápida + implantación. + Afortunadamente pudimos establecer nuestra política de + instalación de SO alrededor de las capacidades predefinidas de + &os;. En una compañía pequeña algunas veces + necesitas ir corriendo a un centro de datos y + rápidamente levantar un servidor para + proporcionar algún servicio. En los dos últimos años, + Argentina.Com adquirió alrededor de cuarenta servidores, la + mayoría Pentium IV pero también varios Xeon duales y unos + cuantos Opteron duales para ubicarlos en los centros de datos + donde tenemos los contratos de operaciones de hosting + y de acceso + telefónico a redes. Todos ellos ejecutan &os;, desde 4.8 + (un par de ellos con dos años de uptime y + cero problemas) hasta 6.0-BETA2. + + La política general que tenemos para con el sistema + operativo consiste en intentar llevar a todos los servidores a la rama + de código estable de una forma periódica utilizando + RELENG_4, RELENG_5 + y ahora RELENG_6. Estas operaciones nos permiten estar + más preparados ante posibles amenazas de seguridad a nivel del + sistema operativo o del software base del mismo, especialmente en los + servidores web. + + + + Reingeniería básica + + El prime paso de reingeniería fue poner en funcionamiento + dos máquinas &os; 4.8 cuya única tarea iba a consistir en + ser DNS autorizados para todos nuestros dominios. El software elegido + resultó ser BIND9. Estas máquinas se ubicaron en diferentes + centros de datos, cuidándonos de asegurar una + buena latencia entre ellos para evitar problemas en transferencias + de zonas, haciendo posible tratar con TTLs entre 60 y 600 segundos + para así poseer unos mejores márgenes de reacción + en caso de problemas. + + El segundo paso consistió en desplegar dos máquinas + más del mismo tipo, también en distintos centros de datos, + para sólo servir Radius y DNS recursivo. Los servidores de + acceso de red (Network Access + Servers o NAS) de los operadores de telecomunicaciones se + configuraron para enviar las peticiones de autorizació y + accounting de Radius hacia los nuestros, y + también para asignar dichos DNS recursivos + a nuestros usuarios de acceso telefónico. + + La tercera regla de oro consiste en no poner + jamás en la misma máquina el servicio de entrada + y salida de correo SMTP. Desplegamos máquinas &os; distintas + utilizando Postfix tanto para la entrada como para la salida. + + + + Migración del correo + + La migración del correo requería una + planificación cuidadosa debido al hecho de que íbamos a + a migrar tanto los frontales como los backends. + El primer paso fue construir un sistema perimetral antispam + y antivirus con &os; 4.x y 5.x basado en postfix, amavisd-new, + clamav y SpamAssassin. Estos sistemas iban a entregar correos + tanto a los antiguos sistemas como a los nuevos hasta que el + nuevo backend estuviera en funcionamiento. + Entre tanto añadimos pequeñas máquinas &os; + para incrementar el spool de correo de + CriticalPath sin ningún problema. + + En la primera línea de la entrada de correo pusimos + varios MX del dominio Argentina.com para filtrar ataques de + diccionario (intentos de reenviar correo a usuarios no existentes) + además de una lista negra derivada de + SURBL que resultó no dar casi ningún falso positivo. + Los correos eran multiplexados hacia un + cluster de Xeon duales y Opteron duales donde ejecutábamos + amavisd-new junto con un filtrado basado en listas blancas y negras + basado en MySQL. Descartamos el uso de Bayes y Autowhitelisting + en un nivel global debido a las grandes cantidades de falsos positivos + y de falsos negativos que proporcionaban. En su lugar definimos unos + cuantos niveles de spam de menos a más tolerante, cada uno con + niveles de corte y de descarte. A cada correo electrónico + recibido el sistema le asigna una determinada puntuación. + Los correos con una puntuación por debajo de la puntuación + asociada con el nivel de corte establecido + por el nivel de spam pueden continuar hasta la bandeja de entrada del + usuario. Los correos entre el nivel de corte y el nivel de descarte se + envían a una carpeta del usuario + denominada Spam, y por último aquellos correos por encima + del nivel de + corte se descartan porque se considera una situación muy + evidente de spam. + En aras de la simplicidad, se asocian de forma transparente los correos + almacenados en la libreta de direcciones con el sistema antispam, + colocándolos en las listas blancas de forma + automática. + + Con la introducción de Spamassassin 3.x, el tráfico + de DNS utilizado para preguntar a las listas negras de correo + creció + considerablemente, de tal forma que firmamos acuerdos con SpamCop, + Spamhaus y SURBL para instalar réplicas públicas de + sus bases de datos en nuestro equipo &os;. Gracias a estas + réplicas, que nos costaron entre 1 y 2Mbps de tráfico, + fuimos capaces de + reducir drásticamente la latencia de Spamassassin. + + En un tercer nivel nos encontramos con la entrega a los + buzones de correo de los usuarios. Tan pronto como nos pusimos + a contruir el nuevo backend Cyrus-Imap con + autentificación MySQL, + nos dimos cuenta de que necesitábamos multiplexar el correo de + entrada a los usuarios en los formatos de los buzones nuevos y + antiguos. Finalmente, conseguimos migrar cientos de miles de + correos hacia la nueva arquitectura Cyrus utilizando una fenomenal + herramienta denominada imapsync, que se puede instalar directamente + desde los ports. También instalamos perdition (un proxy de POP3 y + de IMAP) entre medias para asegurar una migraci´n transparente + y permitir la distribución entre distintos servidores de + los buzones. + En resumen, toda la información de localización de un + buzón de usuario está en MySQL, y dicha información + se encuentra disponible para todo el software que forma parte de + la cadena. + + Respecto al hardware para el espacio de disco, actualmente + utilizamos siete máquinas &os; con Cyrus-Imap de distinto hardware. + El mayor es un Pentium IV con 4G de RAM y tarjetas 3ware + con 12 bahías extraíbles en caliente, + organizadas en 3 unidades RAID-5 + de 1 Terabyte cada una. El software 3ware envía un correo + electrónico al administrador cuando el RAID se degrada + (en la mayoría de los casos se trata de errores de disco) y + es posible reconstruir el RAID con el sistema a pleno rendimiento. + Utilizamos smartmontools en los casos en los que hay + menor redundancia, para disponer inmediatamente de alertas de discos + con problemas de temperatura o de fallos de + selftests. + + Como software de correo web elegimos un producto comercial + denominado Atmail, disponible con sus fuentes en perl y que + utiliza mod_perl. Bajo &os; resulta extremadamente + sencillo gestionar los módulos de perl y no es necesario usar + la shell de CPAN; únicamente hay que seleccionar + el port correcto y ejecutar make install. Tras varios + meses de trabajo de integración pudimos integrar la parte cliente + de Atmail que habla IMAP con nuestros backends. + Tuvimos que modificar algunas partes del código para adaptar + el producto a nuestro entorno libre y para hacerlo compatible con nuestro + perímetro antispam antivirus, además de aplicar + nuestras personalizaciones y traducciones. + + + + Migración web + + Con la adopción de &os; no hubo que realizar ningún + esfuerzo adicional para tener en ejecució en cuestion de minutos + los entornos de Apache, PHP y MySQL. Incluso las actualizaciones de + PHP4 a PHP5 se efectuaron sin problemas. El sistema de ports nos + resultó una vez más extremadamente útil + y nos permitió hacer cosas como comprimir los contenidos de texto y de + html de Apache utilizando unas pocas líneas de + documentación. Además, hemos experimentado + un rendimiento excelente y una estabilidad y uptimes + extraordinarios. + + + + + + Resultados + + Conseguimos implantar una arquitectura de correo electrónico + basada en &os; que es escalable horizontalmente, utilizando 3 + Terabytes de almacenamiento basado en servidores Intel incurriendo + en un coste de 3 dólares por Gigabyte con redundancia. + + La gran estabilidad alcanzada permitió a Argentina.com explorar + otros campos como el hosting para terceros y el + housing con presencia + en los centros de datos argentinos. + + Ahora ofrecemos también acceso telefónico a redes + corporativas para usuarios de roaming y Perú + gracias a nuestra presencia y a los acuerdos suscritos con la + mayoría de los operadores de telecomunicaciones. + Entre nuestros clientes indirectos se encuentran las principales + compañías americanas como Ford, Exxon y Reuters. + También estamos en el negocio del acceso telefónico a redes + en Brasil, Chile, Colombia y Panamá. + + +
+ + diff --git a/es_ES.ISO8859-1/articles/p4-primer/Makefile b/es_ES.ISO8859-1/articles/p4-primer/Makefile new file mode 100644 index 0000000000..a70387182f --- /dev/null +++ b/es_ES.ISO8859-1/articles/p4-primer/Makefile @@ -0,0 +1,19 @@ +# +# $FreeBSD$ +# +# Articulo sobre el uso de Perforce en el desarrollo en FreeBSD. + +DOC?= article + +FORMATS?= html +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.sgml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/es_ES.ISO8859-1/articles/p4-primer/article.sgml b/es_ES.ISO8859-1/articles/p4-primer/article.sgml new file mode 100644 index 0000000000..42d261ec33 --- /dev/null +++ b/es_ES.ISO8859-1/articles/p4-primer/article.sgml @@ -0,0 +1,1005 @@ +$FreeBSD$ + + + + + +%man; + %freebsd; + %newsgroups; + +%authors; + +%trademarks; + +%translators; + %mailing-lists; + +]> + +
+ <application>Perforce</application> en el contexto del desarrollo de &os; + + + + + + Scott + Long + +
scottl@FreeBSD.org +
+ + + + + $FreeBSD$ + + + &tm-attrib.freebsd; + &tm-attrib.cvsup; + &tm-attrib.general; + + + + + Introducción + + El proyecto &os; utiliza el sistema de control de versiones + Perforce para gestionar proyectos + experimentales que todavía no están listos para ser + incluidos en el repositorio principal de CVS. + + + Disponibilidad, documentación 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: + . + + + Existe un cliente gráfico, pero la mayoría de la gente + utiliza la aplicación de línea de órdenes, + p4. Este documento trata sobre el uso de + dicha herramienta para la línea de órdenes. + + En + + encontrará documentación online + detallada. + + Se recomienda encarecidamente leer la guía de + usuario y el manual de Perforce. + La aplicación p4 dispone de una extensa + ayuda online a la que puede accederse mediante la + orden p4 help. + + El servidor &os; Perforce se + encuentra en + perforce.freebsd.org, + puerto 1666. Puede navegar por el + repositorio desde + . + Ciertas partes del repositorio se exportan automáticamente hacia + diversos servidores CVSup. + + + + + 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 contraseña distinta + del acceso de su &os; o de cualquier otro mecanismo de + autenticación SSH: + + &prompt.user; /usr/local/bin/p4newuser + + Por supuesto si no tiene una cuenta en + FreeBSD.org + necesitará 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 operación. Dicha + variable indica el servidor Perforce + con el que se va a trabajar. En el caso del Proyecto &os;, créela + con el siguiente valor: + + &prompt.user; export P4PORT=perforce.freebsd.org:1666 + + + Los usuarios con acceso shell al + cluster + FreeBSD.org + pueden querer encapsular el protocolo cliente-servidor de + Perforce a través de un + túnel SSH, en cuyo caso la variable de arriba + debería establecerse al valor + localhost. + + + El servidor &os; también necesita que se establezcan las + variables P4PASSWD y P4USER. Utilice + el nombre de usuario y la contraseña anteriores del siguiente + modo: + + &prompt.user; export P4USER=nombre_de_usuario +&prompt.user; export P4PASSWD=contraseña + + Compruebe que todo funciona mediante la siguiente + orden: + + &prompt.user; p4 info + + A resultas de esta orden debería ver información + referente al servidor. Si no es así compruebe que + la variable P4PORT tiene el valor correcto. + + + + + Clientes + + El sistema Perforce proporciona + acceso al repositorio y mantiene el estado del cliente de forma + individualizada. En términos de + Perforce, un cliente es una + especificación que asocia + + Este término, que también puede traducirse como + asociar o asignar, suele aparecer en la jerga de la + administración de sistemas como + mapear. + + ficheros y directorios desde el + repositorio hasta la má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í). + El cliente también especifica el directorio raíz del + árbol de + directorios sobre el que se realiza la asociación y la + máquina + donde efectivamente está dicho árbol. Es por esto que + si pretende trabajar en varias máquinas tendrá 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 + continuación: + + + + Client: + + + Este es el nombre de la especificación del cliente. + Puede ser cualquier cosa, pero debe ser una cadena única + dentro del servidor Perforce. Suelen + usarse nombres como + nombre_de_usuario_nombre_de_máquina, + que permite identificar fácilmente a los clientes cuando se + navega por ellos. + Por defecto hay ya un nombre, que se + corresponde con el nombre de la máquina. + + + + + Description: + + + Este campo suele consistir en un breve texto descriptivo + que ayude a identificar al cliente. + + + + + Root: + + + Se trata del directorio local que actuará como + directorio raíz para todos los ficheros dentro de la + asociación en el cliente. + Debe ser una localización única + dentro del sistema + de ficheros que no se solape con otros ficheros o clientes + Perforce. + + + + + Options: + + + La mayoría de las opciones por defecto son correctas y + válidas para todo el mundo, aunque suele ser recomendable + comprobar que estén activadas las opciones + y + y que no tienen el prefijo no. Los + detalles de cada una de estas opciones están en la + documentación de Perforce. + + + + + + LineEnd: + + + Este parámetro gestiona las conversiones CR-LF y debe + dejarse tal cual salvo que sus necesidades específicas + requieran cambiarlo. + + + + + View: + + + Aquí es donde están las asociaciones de ficheros + servidor-a-local. + El valor por defecto es: + + //depot/... //cliente/... + + Esto asociará por completo el repositorio + Perforce al directorio + Root + del cliente. NO USE ESTE VALOR POR DEFECTO. + El repositorio de &os; es enorme e intentar asociarlo y + sincronizarse con dicho repositorio tardará muchísimo y + consumirá enormes recursos. Asocie + sólamente la sección del repositorio en la que va a + trabajar. Por ejemplo, hay un árbol para el proyecto + smpng en //depot/projects/smpng. Una + asociación en ese caso sería algo así: + + //depot/projects/smpng/... //cliente/... + + Los ... deben tomarse literalmente + tal cual están. Es un dialecto de + Perforce para decir este + directorio y todos los ficheros y directorios por debajo de + él.. + + Una vista (View) puede contener múltiples + asociaciones. Vamos a suponer que quiere asociar los + árboles de SMPng + y de NFS. Su View sería algo + así: + + //depot/projects/smpng/... //cliente/smpng/... + //depot/projects/nfs/... //cliente/nfs/... + + Recuerde que cliente es el + nombre del cliente que se especificó en la sección + Client, pero en la sección + View además se utiliza para resolver al + directorio especificado en la sección + Root. + + También tenga en cuenta que el mismo fichero o + directorio no puede asociarse más de una vez dentro de una + única vista. La orden del siguiente ejemplo no es correcta + y producirá 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, así 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 está utilizando, es decir: + + &prompt.user; export P4CLIENT=nombredemicliente + + Fí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ódigo, permitiendo que distintas personas accedan y + modifiquen la misma parte del respositorio. + + + + Sincronizaciones + + Una vez definida la especificación del cliente y una vez + establecida la variable de entorno P4CLIENT, el + siguiente paso consiste en recuperar los ficheros para el cliente en + cuestión desde el servidor hasta la máquina 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 + descargará todos los ficheros. Las siguientes ejecuciones + sólo descargarán aquellos ficheros que hayan cambiado + desde la última ejecución de la orden. + Gracias a esto es posible sincronizar sus fuentes con + las de otras personas con las que esté trabajando. + + Las operaciones de sincronización sólo + atañen 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 ejecución de un + sync no reflejará dichos cambios. No obstante, la + ejecución de p4 sync -f sincrozará + incondicionalmente todos los ficheros, sin que importe su estado. + Esto resulta útil para solucionar problemas cuando se cree que el + árbol pueda haber sufrido algún tipo de + corrupción. + + Puede sincronizarse parte del árbol o del cliente + especificando una ruta relativa a la orden sync. + Por ejemplo, para sincronizar sólo el directorio + ufs + del proyecto smpng ejecute lo + siguiente: + + &prompt.user; cd raizdelproyecto/smpng +&prompt.user; p4 sync src/sys/ufs/... + + El uso de rutas locales relativas funciona en muchas otras + órdenes p4. + + + Ramas + + Una de las características más interesantes de + Perforce es la posibilidad de crear + ramas. Las ramas son muy sencillas de crear y también resulta muy + fácil mover cambios entre distintas ramas (como se verá + más + adelante). Las ramas también 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 árbol principal. Además, + 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 + lógico que cada proyecto disponga de su propia rama y + en &os; recomendamos encarecidamente este esquema. + También se recomienda la aplicación frecuente de los cambios + realizados. + + El repositorio Perforce (conocido + como el depósito, o depot en + la jerga de Perforce) + es un único árbol plano. Se accede a cada fichero a + través de una + sencilla ruta bajo el directorio //depot, tanto si se trata de un + fichero de nueva creación como si proviene de una + ramificació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 Perforce el servidor mantiene las + relaciones entre los ficheros padre e hijo, pero los + ficheros en sí están bajo sus propias rutas. + + + El primer para para crear una rama consiste en crear una + especificación de rama. Es similar a la especificación + de un cliente, + pero se crea mediante la orden p4 branch + nombre_de_rama. + + Veamos los campos más importantes: + + + + Branch + + + El nombre de la rama. Puede ser cualquier nombre, pero + debe ser único en el repositorio. La convención + que se usa en &os; es + nombre_de_usuario_nombre_del_proyecto. + + + + + Description + + + Puede poner aquí un texto simple que describa la + rama. + + + + + View + + + Esto es la asociación de la rama. En lugar de asociar + desde el depósito hacia la máquina local + como una asociación de cliente, se crea una asociación + entre la rama padre y la rama hija + dentro del depósito. Por ejemplo, puede + querer crear una rama del proyecto smpng. La asociación + resultaría 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 &os;: + + //depot/vendor/freebsd/... //depot/projects/mi-nuevo-proyecto/... + + Esto asociará el HEAD del árbol de &os; a su + nueva rama. + + + + + La creación de la especificación de rama + únicamente graba la + especificación en sí misma dentro del servidor. No + modifica el depósito ni cambia + ningún fichero. El directorio que se declara en la rama + permanece vacío 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 está asociado en el cliente. Puede ser + necesario añadir una línea 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 + sección. + + + Integraciones + + Integración es el término que se utiliza + en Perforce para describir la acción de + mover cambios desde una parte del depósito a otra. + Se suele realizar junto con las órdenes creación y + mantenimiento de ramas. Una integració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ún es la integración + periódica desde el árbol original de &os; hacia la rama + hija propia del usuario. + El servidor Perforce + mantiene el estado de los cambios en cada rama y sabe cuándo + hay cambios que pueden integrarse de una rama a otra. + + La forma más común de hacer una integración + se muestra en la siguiente orden: + + + &prompt.user; p4 integrate -b nombrederama + + nombrederama es el nombre que se + ha dado a la + especificación de rama, tal y como se explicó en la + sección anterior. + Esta orden indica a Perforce que + busque cambios en la rama padre que todaví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ón + se realiza por primera vez sobre una rama (por ejemplo cuando se + realiza una operación de rellenado inicial) los ficheros + de la rama padre simplemente se copiarán en la ubicación + en la rama hija de la máquina local. + + Una vez que la operación de integración ha finalizado + se debe ejecutar p4 resolve, que aplicará + los cambios y resolverá 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 rápidamente cómo unir los cambios. + Para ejecutar una operación de resolución + (resolve) utilice las siguientes órdenes: + + &prompt.user; p4 resolve -as +&prompt.user; p4 resolve + + La primera invocación indica a + Perforce que una automáticamente los + cambios y que acepte aquellos ficheros que no den conflictos. La + segunda invocación permite inspeccionar cada fichero con conflictos + y resolver de forma manual dichas incompatiblidades. + + Una vez hecha la integración 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 sección. + + + + Aplicación 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 pérdidas 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. &os; dispone de una platilla personalizada, de la + que a continuación se explican los campos más + importantes: + + Description: + <enter description here> + PR: + Submitted by: + Reviewed by: + Approved by: + Obtained from: + MFP4 after: + + es decir + + Descripción: + <Introduzca una descripción> + PR: + Enviado por: + Revisado por: + Aprobado por: + Obtenido de: + MFP4 tras: + + + Se considera una buena práctica proporcionar al menos dos o + tres frases que describan los cambios entregados. Debería + declarar aquí qué hacen dichos cambios, por qué + se han hecho de esa forma o qué problemas intenta resolver + con ellos. También + conviene explicar qué APIs cambian y qué otros efectos + secundarios pueden tener. + Este texto debe sustituir a la línea <enter + description here> que aparece en la plantilla. Debe + recubrir las líneas y comenzar cada línea con una + tabulación. Las etiquetas de más abajo son + específicas de &os; y puede eliminarlas si no resultan + útiles o apropiadas en su contexto. + + Files: + + Este campo se rellena automáticamente con todos los ficheros + que el cliente etiquetó en el servidor con estados de + adición, borrado, integración o edición. + Le aconsejamos que revise esta lista y elimine de ella los ficheros + que todavía no esten listos. + + Una vez guardada la sesió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án al servidor. Si algo va + mal durante este proceso se cancelará la entrega y se + avisará al usuario de que la entrega se ha convertido en + una lista de cambios que deben corregirse y reenviarse. Las + entregas son atómicas, 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 sí que pueden cancelarse si, dentro + aún del editor, se sale de él sin cambiar el + texto del campo + Description. Perforce + se quejará la primera vez que intente salir y le + devolverá al editor. Si sale por segunda vez el editor + cancelará la operación. Devolver el repositorio + al estado anterior a un cambio ya efectuado es un proceso + muy complicado y no hay un procedimiento estándar, por lo + que depende del caso concreto. + + + + + Edición + + 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 atención a qué + ficheros están abiertos en modo de edición, y utiliza + esa información 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: + + &prompt.user; p4 edit nombredefichero + + Esto marca el fichero en el servidor con el estado de + edición, lo que permite entregar el fichero posteriormente + una vez realizados los cambios oportunos, o lo etiqueta como de + tratamiento especial cuando se está efectuando una + operación de integración o sincronización. + Tenga en cuenta que la edición no es exclusiva en + Perforce. Varias personas pueden tener + el mismo fichero en estado de edición (será + informado de ello si es necesario cuando ejecute + edit), pero podrá entregar sus cambios + incluso cuando haya otras personas que tengan ese fichero en estado + de edición. + + Cuando alguien entregue un cambio de un fichero que usted + esté editando necesitará cotejar sus modificaciones + con las de la otra u otras personas para poder aplicar + correctamente sus modifaciones al repositorio. La forma más + sencilla de hacerlo es ejecutar + p4 sync o p4 submit y dejar + que el programa encuentre algún conflicto, y a + continuación + 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 edición y + quiere descartar los cambios y devolverlo a su estado + original ejecute + p4 revert de la siguiente forma: + + &prompt.user; p4 revert nombredefichero + + Esto resincroniza el fichero con el contenido del servidor y + elimina en el servidor el atributo de edición para ese fichero. + Se perderá cualquier cambio que haya hecho en local. + Esto resulta muy ú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. + + Cuando se sincroniza un fichero se marca como sólo lectura en + el sistema de ficheros. Aunque se pueden sobreescribir fácilmente + 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 están en + estado de edición pueden sobreescribirse al ejecutar + p4 sync. + + + Cambios, descripciones e historial + + Puede ver el historial de cambios realizados al + depósito de + Perforce puede consultarse mediante + p4 changes. Esta orden proporciona una breve + descripción de cada cambio, quién la realizó + y cúal es el número de + modificación. 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 o + 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. + + + + <quote>diffs</quote> + + Existen dos formas de generar diffs de ficheros en + Perforce, bien entre cambios locales + que todavía no se han entregado o bien entre dos + árboles (o dentro de una misma rama) del + depósito. Estos diffs + se generan mediante órdenes distintas, + y : + + + + p4 diff + + + Ese comando genera un diff entre los cambios + locales y los cambios de ficheros en estado de edición. Los + parámetros y + permiten crear diffs unificados o contextuales, + respectivamente. También 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 depósito, o entre + ficheros especificados en una especificación de rama. La + operación tiene lugar en el servidor, así que + la variable P4DIFF no surte ningún efecto, + aunque las opciones y + sí pueden usarse. Las dos formas de + esta orden son: + + &prompt.user; p4 diff2 -b nombrederama + + y + + &prompt.user; p4 diff2 //depot/ruta1 //depot/ruta2 + + + + + En todos los casos los diffs se muestran en la salida + estándar. Por desgracia Perforce + usa un formato de diffs que resulta ser ligeramente + incompatible con las herramientas Unix estándar + diff y patch. La utilización + de la variable P4DIFF para que apunte al verdadero + &man.diff.1; puede paliar este problema, o al menos en ciertos casos, + puesto sólo funciona con la orden + p4 diff. La salida de + debe procesarse para que sea de alguna + utilidad (la opción de + producirá diffs + unificados que serán más o menos + compatibles, pero no esto no incluye ficheros + nuevos o borrados. Este script puede serle + de utilidad para este proceso necesario: + . + + + + Añadir o eliminar ficheros + + La integración de una rama hará que + se añadan ficheros existentes en el servidor en su + árbol, pero quizás sea necesario añadir + nuevos ficheros o eliminar alguno de los ya existentes. + Para añadir ficheros no tiene más que + crear el fichero y ejecutar + p4 add de la siguiente forma: + + &prompt.user; p4 add nombredefichero + + Si quiere añadir un árbol completo de ficheros + ejecute: + + &prompt.user; find . -type f |xargs p4 add + + Al ejecutar p4 submit se copiarán los + ficheros al depósito del servidor. + Es muy importante añadir + sólo ficheros y no directorios. Si se añade + explícitamente un + directorio, Perforce lo tratará como + fichero, lo cual seguramente no es lo que usted tenía + previsto. + + Borrar un fichero es igualmente sencillo mediante + p4 delete: + + &prompt.user; p4 delete nombredefichero + + Esta orden marcará el fichero para que sea borrado del + depósito la siguiente vez que se ejecute una + entrega. + También borrará la copia local del fichero, así 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 sincronización con una versión + previa. La única forma de borrar de forma permanente un + fichero es mediante la orden p4 obliterat. + Dicha orden es irreversible y costosa, así que sólo + está al alcance del personal que administra + el repositorio. + + + + El trabajo con <quote>diffs</quote> + + Algunas veces puede ser necesario aplicar un diff + al árbol + de Perfoce que provenga de otra + aplicación. Si se trata de un diff + de gran tamaño y que afecta a muchos ficheros, puede resultar + tedioso ejecutar manualmente p4 edit sobre cada + fichero. Hay un truco para hacerlo de una forma más sencilla. + En primer lugar, asegúrese de que no hay ficheros abiertos en su + cliente y de que su árbol está sincronizado y actualizado a la + última versión. A continuación aplique + sus cambios mediante las herramientas habituales, y forzando los + permisos de los ficheros en caso de ser necesario. Después + ejecute lo siguiente: + + &prompt.user; p4 diff -se ... |xargs p4 edit +&prompt.user; p4 diff -sd ... |xargs p4 delete +&prompt.user; find . -type f |xargs p4 add + + La primera orden le dice a + Perforce que busque los ficheros que + han cambiado, incluso si no están abiertos. La segunda + orden le dice a Perforce que busque + los ficheros que no existen en la máquina local pero que + sí están en el servidor. La tercera orden intenta + añadir todos los ficheros que están en local. Es + un método de fuerza bruta, pero funciona bien porque + Perforce sólo añadirá + los ficheros que le resulten desconocidos. El resultado de estas + órdenes es un conjunto de ficheros abiertos para edición, + borrado o para ser añadidos, según el caso. Hecho + esto solo nos queda ejecutar + p4 submit para entregar los cambios. + + + + Cambiar nombres de ficheros + + Perforce no dispone de una forma + predefinida de cambiar nombres a ficheros o de moverlos a otra parte + del árbol. Si se copia el fichero en + cuestión a una nueva ubicación mediante p4 + add, y posteriormente p4 + delete en la versión anterior, se obtiene + algo muy parecido a lo que se querí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étodo más recomendable, + que consiste en efectuar una integración dentro del + mismo árbol y de una sola vez. Veamos un ejemplo: + + &prompt.user; p4 integrate -i ficheroprevio ficheronuevo +&prompt.user; p4 resolve +&prompt.user; p4 delete ficheroprevio +&prompt.user; p4 submit + + La integración fuerza a Perforce a + mantener un registro de las relaciones entre los nombres antiguos y + los nuevos, lo cual será muy útil en futuras + integraciones. La opción + indica que se trata de una integración + sin base, es decir, que no existe un historial de + ramas al que recurrir en la integración. Este + parámetro tiene sentido en el presente ejemplo, pero + no debería utilizarse en integraciones basadas en ramas. + + + Interacciones entre el CVS de &os; y Perforce + + Los repositorios de + Perforce y de CVS de &os; están + 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 + árbol //depot/vendor/freebsd/.... + De este modo este árbol permite la ramificación y + la integración de proyectos derivados. Cualquier proyecto + que implique la modificación del código fuente de + &os; debería tener este árbol como su rama padre + (o rama abuela, dependiendo + de las necesidades concretas de cada proyecto), y deberían tener + lugar integraciones periódicas y sincronizaciones para que el + árbol esté en consonancia con el desarrollo de &os; y + evitar conflictos en la medida de lo posible. + + El puente entre CVS y Perforce es + de un sólo sentido; los cambios del CVS se reflejarán en + Perforce, pero los cambios en + Perforce no se reflejarán en el CVS. + Si es necesario, se pueden exportar partes del repositorio de + Perforce al + CVSup y que así se puedan distribuir. + Por favor, contacte con los + administradores de Perforce de &os; si + ese es su caso. + + + + Funcionamiento sin conexión de red + + Uno de los inconvenientes de Perforce es + que supone que siempre es posible acceder al servidor a través + de la red. La mayorí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/CVSup. Es posible + ejecutar un servidor proxy, pero solamente ayuda un poco si se quiere + trabajar sin conexión al servidor. + + La mejor forma de trabajar sin conexión de red es + comprobando que el cliente no tiene ningún fichero abierto y + que está totalmente sincronizado antes de dejar de estar + conectado. + Cuando se edite un fichero se deberán cambiar manualmente + los permisos a lectura-escritura. Cuando vuelva a estar + conectado ejecute la orden que se mostraba + en la para + identificar automáticamente los ficheros que se han editado, + añadido o eliminado. + Es bastante común encontrarse con la sorpresa de que + Perforce ha sobreescrito un fichero + modificado en local que no se abrió en modo edición, + así que tenga especial cuidado con esto. + + + + Consideraciones finales para el <quote>Google Summer of Code</quote> + + La mayoría de los proyectos de &os; dentro del programa + Google Summer of Code están en + //depot/projects/soc2005/nombre_del_proyecto/... + en el servidor &os; de Perforce. + + Entre las responsabilidades del mentor del proyecto + está seleccionar un nombre adecuado para dicho proyecto y + hacer que el estudiante sea capaz de trabajar con + Perforce. + + El acceso al servidor &os; de + Perforce no implica pasar a ser miembro + de la comunidad de committers del CVS de &os;, aunque animamos + de todo corazón a todos los estudiantes que consideren la + posibilidad de unirse al proyecto cuando estén listos + para ello. + +