hgbook
view es/collab.tex @ 1083:ef79008cda9e
2.4.1 first para
| author | Zhaoping Sun <zhaopingsun@gmail.com> |
|---|---|
| date | Fri Nov 20 23:00:06 2009 -0500 (2009-11-20) |
| parents | 801442e58e6d |
| children |
line source
1 \chapter{Colaborar con otros}
2 \label{cha:collab}
4 Debido a su naturaleza descentralizada, Mercurial no impone política
5 alguna de cómo deben trabajar los grupos de personas. Sin embargo, si
6 usted es nuevo al control distribuido de versiones, es bueno tener
7 herramientas y ejemplos a la mano al pensar en posibles modelos de
8 flujo de trabajo.
10 \section{La interfaz web de Mercurial}
12 Mercurial tiene una poderosa interfaz web que provee bastantes
13 capacidades útiles.
15 Para uso interactivo, la interfaz le permite visualizar uno o varios
16 repositorios. Puede ver el historial de un repositorio, examinar cada
17 cambio (comentarios y diferencias), y ver los contenidos de cada
18 directorio y fichero.
20 Adicionalmente la interfaz provee notificaciones RSS de los cambios de los
21 repositorios. Que le permite ``subscribirse''a un repositorio usando
22 su herramienta de lectura de notificaciones favorita, y ser notificado
23 automáticamente de la actividad en el repositorio tan pronto como
24 sucede. Me gusta mucho más este modelo que el estar suscrito a una
25 lista de correo a la cual se envían las notificaciones, dado que no
26 requiere configuración adicional de parte de quien sea que está
27 administrando el repositorio.
29 La interfaz web también permite clonar repositorios a los usuarios
30 remotos, jalar cambios, y (cuando el servidor está configurado para
31 permitirlo) publicar cambios en el mismo. El protocolo de entunelamiento
32 de Mercurial comprime datos agresivamente, de forma que trabaja
33 eficientemente incluso con conexiones de red con poco ancho de banda.
35 La forma más sencilla de iniciarse con la interfaz web es usar su
36 navegador para visitar un repositorio existente, como por ejemplo el
37 repositorio principal de Mercurial \url{http://www.selenic.com/repo/hg?style=gitweb}.
39 Si está interesado en proveer una interfaz web a sus propios
40 repositorios, Mercurial provee dos formas de hacerlo. La primera es
41 usando la orden \hgcmd{serve}, que está enfocada a servir ``de forma
42 liviana'' y por intervalos cortos. Para más detalles de cómo usar
43 esta orden vea la sección~\ref{sec:collab:serve} más adelante. Si
44 tiene un repositorio que desea hacer permanente, Mercurial tiene
45 soporte embebido del \command{ssh} para publicar cambios con seguridad
46 al repositorio central, como se documenta en la
47 sección~\ref{sec:collab:ssh}. Es muy usual que se publique una copia
48 de sólo lectura en el repositorio que está corriendo sobre HTTP usando
49 CGI, como en la sección~\ref{sec:collab:cgi}. Publicar sobre HTTP
50 satisface las necesidades de la gente que no tiene permisos de
51 publicación y de aquellos que quieren usar navegadores web para
52 visualizar el historial del repositorio.
54 \subsection{Trabajo con muchas ramas}
56 Los proyectos de cierta talla tienden naturalmente a progresar de
57 forma simultánea en varios frentes. En el caso del software, es común
58 que un proyecto tenga versiones periódicas oficiales. Una versión
59 puede entrar a ``modo mantenimiento'' por un tiempo después de su
60 primera publicación; las versiones de mantenimiento tienden a contener
61 solamente arreglos de fallos, pero no nuevas características. En
62 paralelo con las versiones de mantenimiento puede haber una o muchas
63 versiones futuras pueden estar en desarrollo. La gente usa normalmente
64 la palabra ``rama'' para referirse a una de las direcciones
65 ligeramente distintas en las cuales procede el desarrollo.
67 Mercurial está especialmente preparado para administrar un buen número
68 de ramas simultáneas pero no idénticas. Cada ``dirección de
69 desarrollo'' puede vivir en su propio repositorio central, y puede
70 mezclar los cambios de una a otra de acuerdo con las necesidades. Dado
71 que los repositorios son independientes, uno del otro, los cambios
72 inestables de una rama de desarrollo nunca afectarán una rama estable
73 a menos que alguien explícitamente mezcle los cambios.
75 A continuación un ejemplo de cómo podría hacerse esto en la
76 práctica. Digamos que tiene una ``rama principal'' en un servidor
77 central.
78 \interaction{branching.init}
79 Alguien lo clona, hace cambios locales, los prueba, y los publica allí
80 mismo.
82 Una vez que la rama principal alcanza una estado de versión se puede
83 usar la orden \hgcmd{tag} para dar un nombre permanente a la revisión.
84 \interaction{branching.tag}
85 Digamos que en la rama principal ocurre más desarrollo.
86 \interaction{branching.main}
87 Cuando se usa la etiqueta con que se identificó la versión, la gente
88 puede clonar el repositorio en cualquier momento en el futuro
89 empleando \hgcmd{update} para obtener una copia del directorio de
90 trabajo exacta como cuando se creó la etiqueta de la revisión que se
91 consignó.
92 \interaction{branching.update}
94 Adicionalmente, justo después de que la rama principal se etiquete,
95 alguien puede clonarla en el servidor a una nueva rama ``estable'',
96 también en el servidor.
97 \interaction{branching.clone}
99 Alguien que requiera hacer un cambio en la rama estable puede clonar
100 \emph{ese} repositorio, hacer sus cambios, consignar y publicarlos
101 posteriormente al inicial.
102 \interaction{branching.stable}
103 Puesto que los repositorios de Mercurial son independientes, y que
104 Mercurial no mueve los cambios de un lado a otro automáticamente, las
105 ramas estable y principal están \emph{aisladas} la una de la otra.
106 Los cambios que haga en la rama principal no ``se filtran'' a la rama
107 estable o vice versa.
109 Es usual que los arreglos de fallos de la rama estable deban hacerse
110 aparecer en la rama principal también. En lugar de reescribir el
111 arreglo del fallo en la rama principal, puede jalar y mezclar los
112 cambios de la rama estable a la principal, Mercurial traerá tales
113 arreglos por usted.
114 \interaction{branching.merge}
115 La rama principal contendrá aún los cambios que no están en la
116 estable y contendrá además todos los arreglos de fallos de la rama
117 estable. La rama estable permanece incólume a tales cambios.
119 \subsection{Ramas de Características}
121 En proyectos grandes, una forma efectiva de administrar los cambios es
122 dividir el equipo en grupos más pequeños. Cada grupo tiene una rama
123 compartida, clonada de una rama ``principal'' que conforma el proyecto
124 completo. Aquellos que trabajan en ramas individuales típicamente
125 están aislados de los desarrollos de otras ramas.
127 \begin{figure}[ht]
128 \centering
129 \grafix{feature-branches}
130 \caption{Ramas de Características}
131 \label{fig:collab:feature-branches}
132 \end{figure}
134 Cuando una rama particular alcanza un estado deseado, alguien del
135 equipo de características jala y fusiona de la rama principal hacia
136 la rama de características y publica posteriormente a la rama principal.
138 \subsection{El tren de publicación}
140 Algunos proyectos se organizan al estilo``tren'': Una versión se
141 planifica para ser liberada cada cierto tiempo, y las características
142 que estén listas cuando ha llegado el momento ``tren'', se incorporan.
144 Este modelo tiene cierta similitud a las ramas de características. La
145 diferencia es que cuando una característica pierde el tren, alguien en
146 el equipo de características jala y fusiona los cambios que se fueron
147 en la versión liberada hacia la rama de característica, y el trabajo
148 continúa sobre lo fusionado para que la característica logre estar en
149 la próxima versión.
151 \subsection{El modelo del kernel linux}
153 El desarrollo del Kernel Linux tiene una estructura jerárquica
154 bastante horizontal, rodeada de una nube de caos aparente. Dado que la
155 mayoría de desarrolladores usan \command{git}, una herramienta distribuida
156 de control de versiones con capacidades similares a Mercurial, resulta
157 de utilidad describir la forma en que el trabajo fluye en tal
158 ambiente; si le gustan las ideas, la aproximación se traduce bien
159 entre Git y Mercurial.
161 En el centro de la comunidad está Linus Torvalds, el creador de Linux.
162 Él publica un único repositorio que es considerado el árbol
163 ``oficial'' actual por la comunidad completa de
164 desarrolladores. Cualquiera puede clonar el árbol de Linus, pero él es
165 muy selectivo acerca de los árboles de los cuales jala.
167 Linus tiene varios ``lugartenientes confiables''. Como regla, él jala
168 todos los cambios que ellos publican, en la mayoría de los casos sin
169 siquiera revisarlos. Algunos de sus lugartenientes generalmente
170 aceptan ser los ``mantenedores'', responsables de subsistemas
171 específicos dentro del kernel. Si un hacker cualquiera desea hacer un
172 cambio a un subsistema y busca que termine en el árbol de Linus, debe
173 encontrar quién es el mantenedor del subsistema y solicitarle que
174 tenga en cuenta su cambio. Si el mantenedor revisa los cambios y está
175 de acuerdo en tomarlos, estos pasarán al árbol de Linus de acuerdo a
176 lo expuesto.
178 Cada lugarteniente tiene su forma particular de revisar, aceptar y
179 publicar los cambios; y para decidir cuando hacerlos presentes a
180 Linus. Adicionalmente existen varias ramas conocidas que mucha gente
181 usa para propósitos distintos. Por ejemplo, pocas personas mantienen
182 repositorios ``estables'' de versiones anteriores del kernel, a los
183 cuales aplican arreglos de fallos críticos necesarios. Algunos
184 mantenedores publican varios árboles: uno para cambios
185 experimentales; uno para cambios que van a ofrecer al mantenedor
186 principal; y así sucesivamente. Otros publican un solo árbol.
188 Este modelo tiene dos características notables. La primera es que son
189 de ``jalar exclusivamente''. Usted debe solicitar, convencer o
190 incluso rogar a otro desarrollador para que tome sus cambios, porque
191 casi no hay árboles en los cuales más de una persona pueda publicar, y
192 no hay forma de publicar cambios en un árbol que otra persona controla.
194 El segundo está basado en reputación y meritocracia. Si usted es un
195 desconocido, Linus probablemente ignorará sus cambios, sin siquiera
196 responderle. Pero un mantenedor de un subsistema probablemente los
197 revisara, y los acogerá en caso de que aprueben su criterio de
198 aplicabilidad. A medida que usted ofrezca ``mejores'' cambios a un
199 mantenedor, habrá más posibilidad de que se confíe en su juicio y se
200 acepten los cambios. Si usted es reconocido y mantiene una rama
201 durante bastante tiempo para algo que Linus no ha aceptado, personas
202 con intereses similares pueden jalar sus cambios regularmente para
203 estar al día con su trabajo.
205 La reputación y meritocracia no necesariamente es transversal entre
206 ``personas'' de diferentes subsistemas. Si usted es respetado pero es
207 un hacker en almacenamiento y trata de arreglar un fallo de redes,
208 tal cambio puede recibir un nivel de escrutinio de un mantenedor de
209 redes comparable con el que se le haría a un completo extraño.
211 Personas que vienen de proyectos con un ordenamiento distinto, sienten
212 que el proceso comparativamente caótico del Kernel Linux es
213 completamente lunático. Es objeto de los caprichos individuales; la
214 gente desecha cambios cuando lo desean; y la fase de desarrollo es
215 alucinante. A pesar de eso Linux es una pieza de software exitosa y
216 bien reconocida.
218 \subsection{Solamente jalar frente a colaboración pública}
220 Una fuente perpetua de discusiones en la comunidad de código abierto
221 yace en el modelo de desarrollo en el cual la gente solamente jala
222 cambios de otros ``es mejor que'' uno en el cual muchas personas
223 pueden publicar cambios a un repositorio compartido.
225 Típicamente los partidarios del modelo de publicar usan las herramientas
226 que se apegan a este modelo. Si usted usa una herramienta
227 centralizada de control de versiones como Subversion, no hay forma de
228 elegir qué modelo va a usar: La herramienta le ofrece publicación
229 compartida, y si desea hacer cualquier otra cosa, va a tener que
230 aplicar una aproximación artificial (tal como aplicar parches a mano).
232 Una buena herramienta distribuida de control de versiones, tal como
233 Mercurial soportará los dos modelos. Usted y sus colaboradores
234 pueden estructurar cómo trabajarán juntos basados en sus propias
235 necesidades y preferencias, sin depender de las peripecias que la
236 herramienta les obligue a hacer.
238 \subsection{Cuando la colaboración encuentra la administración ramificada}
240 Una vez que usted y su equipo configurar algunos repositorios
241 compartidos y comienzan a propagar cambios entre sus repositorios
242 locales y compartidos, comenzará a encarar un reto relacionado, pero
243 un poco distinto: Administrar las direcciones en las cuales su equipo
244 puede moverse. A pesar de que está íntimamente ligado acerca de cómo
245 interactúa su equipo, es lo suficientemente denso para ameritar un
246 tratamiento en el capítulo~\ref{chap:branch}.
248 \section{Aspectos técnicos de la colaboración}
250 Lo que resta del capítulo lo dedicamos a las cuestiones de servir
251 datos a sus colaboradores.
253 \section{Compartir informalmente con \hgcmd{serve}}
254 \label{sec:collab:serve}
256 La orden \hgcmd{serve} de Mercurial satisface de forma espectacular
257 las necesidades de un grupo pequeño, acoplado y de corto
258 tiempo. Se constituye en una demostración de cómo se siente usar los
259 comandos usando la red.
261 Ejecute \hgcmd{serve} dentro de un repositorio, y en pocos segundos
262 iniciará un servidor HTTP especializado; aceptará conexiones desde
263 cualquier cliente y servirá datos de este repositorio mientrs lo
264 mantenga funcionando. Todo el que sepa el URL del servidor que ha
265 iniciado, y que puede comunicarse con su computador por la red, puede
266 usar un navegador web o Mercurial para leer datos del repositorio. Un
267 URL para una instancia de \hgcmd{serve} ejecutándose en un portátil
268 debería lucir algo \Verb|http://my-laptop.local:8000/|.
270 La orden \hgcmd{serve} \emph{no} es un servidor web de propósito
271 general. Solamente puede hacer dos cosas:
272 \begin{itemize}
273 \item Permitir que se pueda visualizar el historial del repositorio que
274 está sirviendo desde navegadores web.
275 \item Hablar el protocolo de conexión de Mercurial para que puedan hacer
276 \hgcmd{clone} o \hgcmd{pull} (jalar) cambios de tal repositorio.
277 \end{itemize}
278 En particular, \hgcmd{serve} no permitirá que los usuarios remotos
279 puedan \emph{modificar} su repositorio. Es de tipo solo lectura.
281 Si está comenzando con Mercurial, no hay nada que le impida usar
282 \hgcmd{serve} para servir un repositorio en su propio computador, y
283 usar posteriormente órdenes como \hgcmd{clone}, \hgcmd{incoming}, para
284 comunicarse con el servidor como si el repositorio estuviera alojado
285 remotamente. Lo que además puede ayudarle a adecuarse rápidamente para
286 usar comandos en repositorios alojados en la red.
288 \subsection{Cuestiones adicionales para tener en cuenta}
290 Dado que permite lectura sin autenticación a todos sus clientes,
291 debería usar \hgcmd{serve} exclusivamente en ambientes en los cuáles
292 no tenga problema en que otros vean, o en los cuales tenga control
293 completo acerca de quien puede acceder a su red y jalar cambios de su
294 repositorio.
296 La orden \hgcmd{serve} no tiene conocimiento acerca de programas
297 cortafuegos que puedan estar instalados en su sistema o en su red. No
298 puede detectar o controlar sus cortafuegos. Si otras personas no
299 pueden acceder a su instancia \hgcmd{serve}, lo siguiente que debería hacer
300 (\emph{después} de asegurarse que tienen el URL correcto) es verificar
301 su configuración de cortafuegos.
303 De forma predeterminada, \hgcmd{serve} escucha conexiones entrantes en
304 el puerto~8000. Si otro proceso está escuchando en tal puerto, usted
305 podrá especificar un puerto distinto para escuchar con la opción
306 \hgopt{serve}{-p}.
308 Normalmente, cuando se inicia \hgcmd{serve}, no imprime nada, lo cual
309 puede ser desconcertante. Si desea confirmar que en efecto está
310 ejecutándose correctamente, y darse cuenta qué URL debería enviar a
311 sus colaboradores, inícielo con la opción \hggopt{-v}.
313 \section{Uso del protocolo Secure Shell (ssh)}
314 \label{sec:collab:ssh}
316 Usted puede publicar y jalar cambios en la red de forma segura usando
317 el protocolo Secure Shell (\texttt{ssh}). Para usarlo satisfactoriamente,
318 tendrá que hacer algo de configuración a nivel de cliente o el
319 servidor.
321 Si no está familiarizado con ssh, es un protocolo de red que le permite
322 comunicarse con seguridad con otro computador. Para usarlo con
323 Mercurial, estará estableciendo una o más cuentas de usuario en un
324 servidor de forma tal que los usuarios remotos puedan entrar y
325 ejecutar órdenes.
327 (Si ssh le \emph{es} familiar, encontrará probablemente elemental una
328 porción del material a continuación.)
330 \subsection{Cómo leer y escribir URLs de ssh}
332 Los URLs de ssh tienden a lucir de la siguiente forma:
333 \begin{codesample2}
334 ssh://bos@hg.serpentine.com:22/hg/hgbook
335 \end{codesample2}
336 \begin{enumerate}
337 \item La parte ``\texttt{ssh://}'' indica a Mercurial que use el
338 protocolo ssh.
339 \item El componente ``\texttt{bos@}'' indica el nombre del usuario que
340 está entrando al servidor. Puede omitirlo si el usuario remoto
341 coincide con el usuario local.
342 \item ``\texttt{hg.serpentine.com}'' es el nombre del servidor al cual
343 se desea entrar.
344 \item El ``:22'' identifica el número del puerto en el servidor al cual
345 se conectará. El predeterminado es el~22, así que solamente
346 necesitará especificar esa porción si \emph{no} está usando el
347 puerto~22.
348 \item La última porción del URL es la ruta local al repositorio en el
349 servidor.
350 \end{enumerate}
352 El componente de la ruta del URL para ssh es una fuente de confusión,
353 puesto que no hay una forma estándar para que las herramientas puedan
354 interpretarlo. Algunos programas se comportan de manera distinta a
355 otros cuando manipulan estas rutas. No es la situación ideal, pero
356 es muy poco probable que vaya a cambiar. Por favor lea los párrafos
357 siguientes cuidadosamente.
359 Mercurial trata la ruta al repositorio en el servidor como relativo al
360 directorio personal del usuario remoto. Por ejemplo, si el usuario
361 \texttt{foo} en el servidor tiene el directorio casa
362 \dirname{/home/foo},
363 entonces un URL ssh que contenga en su ruta a \dirname{bar}
364 \emph{realmente} se refiere al directorio \dirname{/home/foo/bar}.
366 Si desea especificar una ruta relativa a otro directorio de usuario,
367 puede usar una ruta que comience con un caracter tildado, seguido del
368 nombre del usuario (llamémosle \texttt{otrousuario}, así
369 \begin{codesample2}
370 ssh://server/~otrousuario/hg/repo
371 \end{codesample2}
373 Y si realmente desea especifica una ruta \emph{absoluta} en el
374 servidor, comience con el componente de la ruta con dos barras como
375 en el siguiente ejemplo:
376 \begin{codesample2}
377 ssh://server//absolute/path
378 \end{codesample2}
380 \subsection{Encontrar un cliente ssh para su sistema}
382 Casi todos los sistemas tipo Unix vienen con OpenSSH preinstalado. Si
383 usted está usando un sistema de estos, ejecute \Verb|which ssh| para
384 identificar dónde está instalada la orden \command{ssh} (usualmente
385 estará en \dirname{/usr/bin}). Si por casualidad no está presente,
386 vea la documentación de sus sistema para lograr instalarlo.
388 En Windows, tendrá que escoger primero un cliente adecuado para
389 descargarlo. Hay dos alternativas:
390 \begin{itemize}
391 \item El excelente paquete PuTTY~\cite{web:putty} de Simon Tatham, que
392 ofrece un suite completo de órdenes de cliente ssh.
393 \item Si tiene alta tolerancia al dolor, puede usar el porte de Cygwin
394 para OpenSSH.
395 \end{itemize}
396 En cualquier caso, tendrá que editar su fichero \hgini\ para indicarle
397 a Mercurial dónde encontrar la orden real del cliente. Por ejemplo, si
398 está usando PuTTY, tendrá que usar la orden \command{plink} como un
399 cliente de línea de órdenes.
400 \begin{codesample2}
401 [ui]
402 ssh = C:/ruta/a/plink.exe -ssh -i "C:/ruta/a/mi/llave/privada"
403 \end{codesample2}
405 \begin{note}
406 La ruta a \command{plink} no debería contener espacios o caracteres
407 en blanco, o Mercurial no podrá encontrarlo correctamente (por lo
408 tanto, probablemente no sería buena idea colocarlo en
409 \dirname{C:\\Program Files}
410 \end{note}
412 \subsection{Generar un par de llaves}
414 Para evitar la necesidad de teclear una clave de forma repetitiva cada
415 vez que necesita usar el cliente, recomiendo generar un par de llaves.
416 En un sistema tipo Unix, la orden \command{ssh-keygen} también se
417 comportará bien. En Windows, si está usando PuTTY, la orden
418 \command{puttygen} es la que necesitará.
420 Cuando genera un par de llaves, se aconseja \emph{comedidamente}
421 protegerlas con una frase de clave. (La única oportunidad en la cual
422 usted querría identificarse una única vez, es cuando está usando
423 el protocolo ssh para tareas automatizadas en una red segura.)
425 No basta con generar un par de llaves. Se requiere adicionar una llave
426 pública al conjunto de llaves autorizadas para todos los usuarios
427 remotos que se vayan a autenticar. Para aquellos servidores que usen
428 OpenSSH (la gran mayoría), significará añadir la llave pública a la
429 lista en el fichero llamado \sfilename{authorized\_keys} en su
430 directorio \sdirname{.ssh}.
432 En sistemas tipo Unix, su llave pública tendrá la extensión
433 \filename{.pub}. Si usa \command{puttygen} en Windows, puede
434 guardar la llave pública en un fichero de su elección, o pegarla desde
435 la ventana en la cual se despliega directamente en el fichero
436 \sfilename{authorized\_keys}.
438 \subsection{Uso de un agente de autenticación}
440 Un agente de autenticación es un demonio que almacena frases clave en
441 memoria (olvidará las frases clave si sale y vuelve a entrar). Un cliente
442 ssh notará si está corriendo, y solicitará una frase clave. Si no hay
443 un agente de autenticación corriendo, o el agente no almacena la frase
444 clave necesaria, tendrá que teclear su frase clave cada vez que
445 Mercurial intente comunicarse con un servidor para usted (p.e.~cada vez
446 que jale o publique cambios).
448 El problema de almacenar frases claves en un agente es que es posible
449 para un atacante bien preparado recuperar el texto plano de su frase
450 clave, en algunos casos incluso si su sistema sea muy alternante.
451 Es su decisión si es un riesgo aceptable. Lo que si es seguro es que
452 evita reteclear.
454 En sistemas tipo Unix, el agente se llama \command{ssh-agent}, y
455 usualmente se ejecuta automáticamente cuando usted entra. Tendrá que
456 usar la orden \command{ssh-add} para añadir frases claves al agente. En
457 Windows, si está usando PuTTY, la orden \command{pageant} actúa como
458 el agente. Añade un icono a su barra del sistema que le permitirá
459 almacenar frases clave.
461 \subsection{Configurar el lado del servidor apropiadamente}
463 Dado que puede ser dispendioso configurar ssh si usted es nuevo, hay
464 una variedad de cosas que podrían ir mal. Añada piense primero en
465 Mercurial y hay mucho más en qué pensar. La mayor parte de estos
466 problemas potenciales ocurren en el lado del servidor, no en el cliente.
467 Las buenas noticias es que una vez tiene una configuración funcional,
468 usualmente continuará trabajando indefinidamente.
470 Antes de intentar que Mercurial hable con un servidor ssh, es mejor
471 asegurarse que puede usar la orden normal \command{ssh} o \command{putty}
472 para comunicarse con el servidor primero. Si tiene problemas usando
473 estas órdenes directamente, de seguro Mercurial no funcionará. Pero aún,
474 esconderá el problema subyacente. Cuando desee revisar un problema
475 relacionado con ssh y Mercurial, debería asegurarse primero que las
476 órdenes de ssh en el lado del cliente funcionan primero, \emph{antes}
477 de preocuparse por si existe un problema con Mercurial.
479 Lo primero para asegurar en el lado del servidor es que puede entrar
480 desde otra máquina. Si no puede entrar con \command{ssh} o
481 \command{putty}, el mensaje de error que obtenga le puede dar pistas
482 de qué ha ido mal. Los problemas más comunes son los siguientes:
483 \begin{itemize}
484 \item Si obtiene un error de ``conexión rehusada'', es posible que no
485 haya un demonio SSH corriendo en el servidor o que no pueda accederse
486 a él por configuraciones de cortafuegos.
487 \item Si obtiene un error de ``no hay ruta hasta el servidor'', puede
488 tener la dirección del servidor incorrecta o un cortafuegos con
489 bloqueo agresivo que no permitirá su existencia.
490 \item Si obtiene un mensaje de ``permiso denegado'', puede que haya
491 tecleado mal el usuario en el servidor, o que haya tecleado
492 incorrectamente la frase clave o la clave del usuario remoto.
493 \end{itemize}
494 En resumen, si tiene problemas al comunicarse con el demonio ssh del
495 servidor, primero asegúrese de que está corriendo. En muchos sistemas
496 estará instalado, pero deshabilitado de forma predeterminada. Una vez
497 que haya hecho este paso tendrá que revisar si el cortafuegos del
498 servidor está configurado para recibir conexiones entrantes en el
499 puerto en el cual el demonio de ssh está escuchando (usualmente el~22).
500 No trate de buscar otras posibilidades exóticas o configuraciones
501 erradas hasta que haya revisado primero estas dos.
503 Si está usando un agente de autenticación en el lado del cliente para
504 almacenar las frase claves de sus contraseñas, debería poder entrar al
505 servidor sin necesidad de que se le solicite frases claves o
506 contraseñas. Si se le pregunta alguna, a continuación algunas
507 posibilidades:
508 \begin{itemize}
509 \item Puede haber olvidado usar \command{ssh-add} o
510 \command{pageant} para guardar la frase clave.
511 \item Puede haber almacenado una frase clave errónea para la llave.
512 \end{itemize}
513 Si se le solicita la clave del usuario remoto, hay otras posibilidades
514 que deben revisarse:
515 \begin{itemize}
516 \item O bien el directorio del usuario o su directorio \sdirname{.ssh}
517 tiene permisos excesivamente abiertos. Como resultado el daemonio
518 ssh no creerá o leerá su fichero \sfilename{authorized\_keys}.
519 Por ejemplo, un directorio casa o \sdirname{.ssh} causará aveces
520 este síntoma.
521 \item El fichero de usuario \sfilename{authorized\_keys} puede tener
522 un problema. Si alguien distinto al usuario es dueño o puede
523 escribir el fichero, el demonio ssh no confiará o lo leerá.
524 \end{itemize}
526 En un mundo ideal, debería poder ejecutar la siguiente orden
527 exitosamente, y debería imprimir exactamente una línea de salida,
528 la fecha y hora actual.
529 \begin{codesample2}
530 ssh miservidor fecha
531 \end{codesample2}
533 Si en su servidor tiene guión que se ejecuta a la entrada e imprime
534 letreros o cualquier otra cosa, incluso cuando se ejecutan órdenes no
535 interactivas como esta, debería arreglarlo antes de continuar, de
536 forma que solamente imprima algo si se ejecuta interactivamente. De
537 otra forma estos letreros al menos llenarán la salida de Mercurial.
538 Incluso podrían causar problemas potenciales cuando se ejecuten
539 órdenes de forma remota. Mercurial intenta detectar e ignorar los
540 letreros en sesiones no interactivas de \command{ssh}, pero no es
541 a prueba de tontos. (Si edita sus guiones de entrada en el servidor,
542 la forma usual de ver si un guión de línea de comandos se ejecuta en un intérprete
543 interactivo, es verificar el código de retorno de la orden
544 \Verb|tty -s|.)
546 Cuando verifique que el venerado ssh funciona en su servidor, el
547 paso siguiente es asegurar que Mercurial corre en el servidor. La
548 orden siguiente debería ejecutarse satisfactoriamente:
549 \begin{codesample2}
550 ssh miservidor hg version
551 \end{codesample2}
552 Si ve un mensaje de error en lugar de la salida usual de
553 \hgcmd{version}, será porque no ha instalado Mercurial en
554 \dirname{/usr/bin}. No se preocupe si este es el caso; no necesita
555 hacerlo. Pero debería revisar los posibles problemas presentados a
556 continuación:
557 \begin{itemize}
558 \item Está instalado Mercurial en el servidor? Se que suena trivial
559 pero es mejor revisar!
560 \item Tal vez la ruta de búsqueda de la interfaz de órdenes
561 (normalmente vía la variable de ambiente \envar{PATH}) simplemente
562 está mal configurada.
563 \item Puede ser que su variable de ambiente \envar{PATH} soalamente
564 apunte al lugar en el cual está el ejecutable \command{hg} si la
565 sesión de entrada es interactiva. Puede suceder si establece la
566 ruta en el guión de línea de comandos de entrada incorrecto. Consulte la
567 documentación de su línea de órdenes.
568 \item La variable de ambiente \envar{PYTHONPATH} puede requerir la
569 ruta a los módulos de Mercurial en Python. Puede que ni siquiera
570 está establecida; podría estar incorrecta; o puede ser que se
571 establezca únicamente cuando hay entradas interactivas.
572 \end{itemize}
574 Si puede ejecutar \hgcmd{version} sobre una conexión ssh,
575 felicitaciones! Ha logrado la interacción entre el cliente y el
576 servidor. Ahora debería poder acceder a los repositorios de
577 Mercurial que tiene el usuario en el servidor. Si tiene problemas
578 con Mercurial y ssh en este punto, intente usar la opción
579 \hggopt{--debug} para tener información más clara de lo que está
580 sucediendo.
582 \subsection{Compresión con ssh}
584 Mercurial no comprime datos cuando usa el protocolo ssh, dado que
585 el protocolo puede comprimir datos transparentemente. Pero el
586 comportamiento predeterminado del cliente ssh es \emph{no}
587 solicitar compresión.
589 Sobre cualquier red distinta a una LAN rápida (incluso con una red
590 inalámbrica), hacer uso de compresión puede mejorar el rendimiento
591 de las operaciones de Mercurial que involucren la red. Por ejemplo,
592 sobre WAN, alguien ha medido la compresión reduciendo la cantidad
593 de tiempo requerido para clonar un repositorio particularmente
594 grande de~51 minutos a~17 minutos.
596 Tanto \command{ssh} como \command{plink} aceptan la opción
597 \cmdopt{ssh}{-C} que activa la compresión. Puede editar fácilmente
598 su \hgrc\ para habilitar la compresión para todos los usos de
599 Mercurial sobre el protocolo ssh.
600 \begin{codesample2}
601 [ui]
602 ssh = ssh -C
603 \end{codesample2}
605 Si usa \command{ssh}, puede reconfigurarlo para que siempre use
606 compresión cuando se comunique con su servidor. Para hacerlo,
607 edite su fichero \sfilename{.ssh/config} (que puede no existir
608 aún), de la siguiente forma:
609 \begin{codesample2}
610 Host hg
611 Compression yes
612 HostName hg.ejemplo.com
613 \end{codesample2}
614 Que define un alias, \texttt{hg}. Cuando lo usa con la orden
615 \command{ssh} o con una URL de Mercurial con protocolo\texttt{ssh},
616 logrará que \command{ssh} se conecte a \texttt{hg.ejemplo.com}
617 con compresión. Que le dará un nombre más corto para teclear y
618 compresión, los cuales por derecho propio son buenos.
620 \section{Uso de CGI a través de HTTP}
621 \label{sec:collab:cgi}
623 Dependiendo de qué tan ambicioso sea, configurar la interfaz CGI
624 de Mercurial puede tomar desde unos minutos hasta varias horas.
626 Comenzaremos con el ejemplo más sencillo, y nos dirigiremos hacia
627 configuraciones más complejas. Incluso para el caso más básico
628 necesitará leer y modificar su configuración del servidor web.
630 \begin{note}
631 Configurar un servidor web es una actividad compleja, engorrosa y
632 altamente dependiente del sistema. De ninguna manera podremos
633 cubrir todos los casos posibles con los cuales pueda encontrarse.
634 Use su discreción y juicio respecto a las secciones siguientes.
635 Esté preparado para cometer muchas equivocaciones, y emplear
636 bastante tiempo leyendo sus bitácoras de error del servidor.
637 \end{note}
639 \subsection{Lista de chequeo de la configuración del servidor web}
641 Antes de continuar, tómese un tiempo para revisar ciertos aspectos de
642 la configuración de su sistema:
644 \begin{enumerate}
645 \item ¿Tiene un servidor web? Mac OS X viene con Apache, pero otros
646 sistemas pueden no tener un servidor web instalado.
647 \item Si tiene un servidor web instalado, ¿Está ejecutándose? En la
648 mayoría de sistemas, aunque esté presente, puede no estar habilitado
649 de forma predeterminada.
650 \item ¿u servidor está configurado para permitir ejecutar programas
651 CGI en el directorio donde planea hacerlo? Casi todos los
652 servidores de forma predeterminada explícitamente inhiben la
653 habilidad de ejecutar programas CGI.
654 \end{enumerate}
656 Si no tiene un servidor web instalado, y no tiene cierta experiencia
657 configurando Apache, debería considerar usar el servidor web
658 \texttt{lighttpd} en lugar de Apache. Apache tiene una reputación
659 bien ganada por su configuración barroca y confusa.
660 A pesar de que \texttt{lighttpd} tiene menos características que
661 Apache en ciertas áreas, las mismas no son relevantes para servir
662 repositorios de Mercurial. Definitivamente es mucho más sencillo
663 comenzar con \texttt{lighttpd} que con Apache.
665 \subsection{Configuración básica de CGI}
667 En sistemas tipo Unix es común que los usuarios tengan un subdirectorio
668 con un nombre como \dirname{public\_html} en su directorio personal,
669 desde el cual pueden servir páginas web. Un fichero llamado \filename{foo}
670 en este directorio será visible en una URL de la forma
671 \texttt{http://www.example.com/\~username/foo}.
673 Para comenzar, encuentre el guión \sfilename{hgweb.cgi} que debería
674 estar presente en su instalación de Mercurial. Si no puede
675 encontrarlo rápidamente una copia local en su sistema, puede
676 descargarlo del repositorio principal de Mercurial en
677 \url{http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi}.
679 Tendrá que copiar este guión en su directorio \dirname{public\_html},
680 y asegurarse que sea ejecutable.
681 \begin{codesample2}
682 cp .../hgweb.cgi ~/public_html
683 chmod 755 ~/public_html/hgweb.cgi
684 \end{codesample2}
685 El argumento \texttt{755} de la orden \command{chmod} es un poco más
686 general que hacerlo ejecutable: Asegura que el guión sea ejecutable
687 por cualquiera, y que el ``grupo'' y los ``otros'' \emph{no} tengan
688 permiso de escritura. Si dejara los permisos de escritura abiertos,
689 , el subsistema \texttt{suexec} de Apache probablemente se negaría
690 a ejecutar el guión. De hecho, \texttt{suexec} también insiste en que
691 el \emph{directorio} en el cual reside el guión no tenga permiso de
692 escritura para otros.
693 \begin{codesample2}
694 chmod 755 ~/public_html
695 \end{codesample2}
697 \subsubsection{¿Qué \emph{podría} resultar mal?}
698 \label{sec:collab:wtf}
700 Cuando haya ubicado el CGI en el sitio correspondiente con un navegador
701 intente visitar el URL \url{http://myhostname/~myuser/hgweb.cgi},
702 \emph{sin} dejarse abatir por un error. Hay una alta probabilidad de
703 que esta primera visita al URL sea fallida, y hay muchas razones posibles
704 para este comportamiento. De hecho, podría toparse con cada uno de los
705 errores que describimos a continuación, así que no deje de leerlos
706 cuidadosamente. A continuación presento los problemas que yo tuve en
707 un sistema con Fedora~7, con una instalación nueva de Apache, y una
708 cuenta de usuario que creé específicamente para desarrollar este
709 ejercicio.
711 Su servidor web puede tener directorios por usuario deshabilitados. Si
712 usa Apache, busque el fichero de configuración que contenga la
713 directiva \texttt{UserDir}. Si no está presente en sitio alguno, los
714 directorios por usuario están deshabilitados. Si la hay, pero su
715 valor es \texttt{disabled}, los directorios por usuario estarán
716 deshabilitados. La directiva \texttt{UserDir} en caso contrario tendrá
717 el nombre del subdirectorio bajo el cual Apache mirará en el
718 directorio de cada usuario, por ejemplo \dirname{public\_html}.
720 Los permisos de sus ficheros pueden ser demasiado restrictivos. El
721 servidor web debe poder recorrer su directorio personal y los
722 directorios que estén bajo \dirname{public\_html}, además de tener
723 permiso para leer aquellos que estén adentro. A continuación una
724 receta rápida para hacer que sus permisos estén acordes con las
725 necesidades básicas.
726 \begin{codesample2}
727 chmod 755 ~
728 find ~/public_html -type d -print0 | xargs -0r chmod 755
729 find ~/public_html -type f -print0 | xargs -0r chmod 644
730 \end{codesample2}
732 Otra posibilidad con los permisos es que obtenga una ventana
733 completamente en blanco cuando trata de cargar el guión. En cuyo
734 caso, es posible que los permisos que tiene son \emph{demasiado
735 permisivos}. El subsistema \texttt{suexec} de Apache no ejecutará un
736 guión que tenga permisos de escritura para el grupo o el planeta, por
737 ejemplo.
739 Su servidor web puede estar configurado para evitar la ejecución de
740 programas CGI en los directorios de usuario. A continuación presento
741 una configuración predeterminada por usuario en mi sistema Fedora.
743 \begin{codesample2}
744 <Directory /home/*/public_html>
745 AllowOverride FileInfo AuthConfig Limit
746 Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
747 <Limit GET POST OPTIONS>
748 Order allow,deny
749 Allow from all
750 </Limit>
751 <LimitExcept GET POST OPTIONS>
752 Order deny,allow
753 Deny from all
754 </LimitExcept>
755 </Directory>
756 \end{codesample2}
757 Si encuentra un grupo de instrucciones de \texttt{Directory} similares
758 en su configuración de Apache, la directiva a revisar es \texttt{Options}.
759 Adicione \texttt{ExecCGI} al final de esta lista en caso de que haga
760 falta y reinicie su servidor web.
762 Si resulta que Apache le muestra el texto del guión CGI en lugar de
763 ejecutarlo, necesitará o bien descomentar (si se encuentra presente) o
764 adicionar una directiva como la siguiente:
765 \begin{codesample2}
766 AddHandler cgi-script .cgi
767 \end{codesample2}
769 Otra posibilidad es que observe una traza de Python en colores
770 informando que no puede importar un módulo relacionado con
771 \texttt{mercurial}. Esto es un gran progreso! El servidor es capaz
772 de ejecutar su guión CGI. Este error solamente ocurrirá si está
773 ejecutando una instalación privada de Mercurial en lugar de una
774 instalación para todo el sistema. Recuerde que el servidor que
775 ejecuta el programa CGI no cuenta con variables de ambiente de las
776 cuales usted si dispone en una sesión interactiva. Si este error le
777 ocurre, edite su copia de \sfilename{hgweb.cgi} y siga las indicaciones
778 dentro del mismo para establecer de forma adecuada su variable de
779 ambiente \envar{PYTHONPATH}.
781 Finalmente, si encuentra \emph{otra} traza a todo color de Python al visitar
782 el URL: Esta seguramente se referirá a que no puede encontrar
783 \dirname{/path/to/repository}. Edite su script \sfilename{hgweb.cgi}
784 y reemplace la cadena \dirname{/path/to/repository} con la ruta
785 completa al repositorio que desea servir.
787 En este punto, cuando trate de recargar la página, deberá visualizar
788 una linda vista HTML del historial de su repositorio. Uff!
790 \subsubsection{Configuración de lighttpd}
792 En mi intención de ser exhaustivo, intenté configurar
793 \texttt{lighttpd}, un servidor web con creciente aceptación, para
794 servir los repositorios de la misma forma como lo describí
795 anteriormente con Apache. Después de superar los problemas que mostré
796 con Apache, muchos de los cuáles no son específicos del servidor. Por
797 lo tanto estaba seguro de que mis permisos para directorios y ficheros
798 eran correctos y que mi guión \sfilename{hgweb.cgi} también lo era.
800 Dado que ya Apache estaba en ejecución correctamente, lograr que
801 \texttt{lighttpd} sirviera mi repositorio fue rápido (en otras
802 palabras, si está tratando de usar \texttt{lighttpd}, debe leer la
803 sección de Apache). Primero tuve que editar la sección
804 \texttt{mod\_access} para habilitar \texttt{mod\_cgi} y
805 \texttt{mod\_userdir}, los cuales estaban inhabilitados en mi
806 instalación predeterminada. Añadí posteriormente unas líneas al final
807 del fichero de configuración, para hacer lo propio con los módulos.
808 \begin{codesample2}
809 userdir.path = "public_html"
810 cgi.assign = ( ".cgi" => "" )
811 \end{codesample2}
812 Hecho esto, \texttt{lighttpd} funcionó inmediatamente para
813 mí. Configuré \texttt{lighttpd} antes que Apache, tuve casi los mismos
814 reparos a nivel de configuración del sistema que con Apache. De todas
815 maneras, considero que \texttt{lighttpd} es bastante más sencillo de
816 configurar que Apache, a pesar de haber usado Apache por lo menos por
817 una década, y esta fue mi primera experiencia con \texttt{lighttpd}.
819 \subsection{Compartir varios repositorios con un guión CGI}
821 El guión \sfilename{hgweb.cgi} permite publicar únicamente un
822 repositorio, una restricción frustrante. Si desea publicar más de uno
823 sin complicarse con varias copias del mismo guión, cada una con un
824 nombre distinto, resulta mucho mejor usar el guión
825 \sfilename{hgwebdir.cgi}.
827 El procedimiento para configurar \sfilename{hgwebdir.cgi} tiene una
828 porción adicional frente al trabajo requerido con
829 \sfilename{hgweb.cgi}. Primero se debe obtener una copia del
830 guión. Si no tiene una a mano, puede descargar una copia del ftp
831 principal del repositorio de Mercurial en
832 \url{http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi}.
834 Necesitará una copia del guión en su directorio \dirname{public\_html},
835 y asegurarse de que sea ejecutable.
836 \begin{codesample2}
837 cp .../hgwebdir.cgi ~/public_html
838 chmod 755 ~/public_html ~/public_html/hgwebdir.cgi
839 \end{codesample2}
840 Con la configuración básica, intente visitar en su navegador
841 \url{http://myhostname/~myuser/hgwebdir.cgi}. Debería mostrar una
842 lista vacía de repositorios. Si obtiene una ventana en blanco o un
843 mensaje de error, verifique la lista de problemas potenciales en la
844 sección~\ref{sec:collab:wtf}.
846 El guión \sfilename{hgwebdir.cgi} se apoya en un fichero externo de
847 configuración. En principio, busca un fichero llamado
848 \sfilename{hgweb.config} en el mismo directorio. Tendrá que crear el
849 fichero, y permitir lectura de todo el mundo. El formato del fichero
850 es similar a un fichero ``ini'' de Windows, que puede interpretar el módulo
851 \texttt{ConfigParser}~\cite{web:configparser} de Python.
853 La forma más sencilla de configurar \sfilename{hgwebdir.cgi} es con
854 una sección llamada \texttt{collections}. Esta publicará automáticamente
855 \emph{todos} los repositorios en los directorios que usted
856 especifique. La sección debería lucir así:
857 \begin{codesample2}
858 [collections]
859 /mi/ruta = /mi/ruta
860 \end{codesample2}
861 Mercurial lo interpreta buscando el nombre del directorio que esté a la
862 \emph{derecha} del símbolo ``\texttt{=}''; encontrando repositorios en
863 la jerarquía de directorios; y usando el texto a la \emph{izquierda}
864 para eliminar el texto de los nombres que mostrará en la interfaz
865 web. El componente restante de la ruta después de esta eliminación
866 usualmente se llama ``ruta virtual''.
868 Dado el ejemplo de arriba, si tenemos un repositorio cuya ruta local es
869 \dirname{/mi/ruta/este/repo}, el guión CGI eliminará la porción inicial
870 \dirname{/mi/ruta} del nombre y publicará el repositorio con una ruta
871 virtual \dirname{este/repo}. Si el URL base de nuestro guión CGI es
872 \url{http://myhostname/~myuser/hgwebdir.cgi}, el URL completo al
873 repositorio será
874 \url{http://myhostname/~myuser/hgwebdir.cgi/this/repo}.
876 Si reemplazamos \dirname{/mi/ruta} en el lado izquierdo de este
877 ejemplo con \dirname{/mi}, \sfilename{hgwebdir.cgi} eliminará solamente
878 \dirname{/mi} del nombre del repositorio, y nos ofrecerá la ruta
879 virtual \dirname{ruta/este/repo} en lugar de \dirname{este/repo}.
881 El guión \sfilename{hgwebdir.cgi} buscará recursivamente en cada
882 directorio listado en la sección \texttt{collections} de su fichero de
883 configuración, pero \texttt{no} hará el recorrido recursivo dentro de
884 los repositorios que encuentre.
886 El mecanismo de \texttt{collections} permite publicar fácilmente
887 repositorios de una forma ``hacer y olvidar''. Solamente requiere
888 configurar el guión CGI y el fichero de configuración una vez.
889 Después de eso puede publicar y sacar de publicación un repositorio en
890 cualquier momento incluyéndolo o excluyéndolo de la jerarquía de
891 directorios en la cual le haya indicado a \sfilename{hgwebdir.cgi} que
892 mirase.
894 \subsubsection{Especificación explícita de los repositorios a publicar}
896 Además del mecanismo \texttt{collections}, el guión
897 \sfilename{hgwebdir.cgi} le permite publicar una lista específica de
898 repositorios. Para hacerlo, cree una sección \texttt{paths}, con los
899 contenidos de la siguiente forma:
900 \begin{codesample2}
901 [paths]
902 repo1 = /mi/ruta/a/un/repo
903 repo2 = /ruta/a/otro/repo
904 \end{codesample2}
905 En este caso, la ruta virtual (el componente que aparecerá en el URL)
906 está en el lado derecho de cada definición, mientras que la ruta al
907 repositorio está a la derecha. Note que no tiene que haber relación
908 alguna entre la ruta virtual que elija y el lugar del repositorio en
909 su sistema de ficheros.
911 Si lo desea, puede usar los dos mecanismos \texttt{collections} y
912 \texttt{paths} simultáneamente en un sólo fichero de configuración.
914 \begin{note}
915 Si varios repositorios tienen la misma ruta virtual,
916 \sfilename{hgwebdir.cgi} no reportará error. Pero se comportará
917 impredeciblemente.
918 \end{note}
920 \subsection{Descarga de ficheros fuente}
922 La interfaz web de Mercurial permite a los usuarios descargar
923 un conjunto de cualquier revisión. Este fichero contendrá una réplica
924 del directorio de trabajo en la revisión en cuestión, pero no
925 contendrá una copia de los datos del repositorio.
927 De forma predeterminada esta característica no está habilitada. Para
928 lograrlo adicione un \rcitem{web}{allow\_archive} a la sección \rcsection{web}
929 de su fichero \hgrc.
931 \subsection{Opciones de configuración en Web}
933 Las interfaces web de Mercurial (la orden \hgcmd{serve}, y los guiones
934 \sfilename{hgweb.cgi} y \sfilename{hgwebdir.cgi}) tienen varias
935 opciones de configuración para establecer. Todas ellas en la sección
936 \rcsection{web}.
937 \begin{itemize}
938 \item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de ficheros
939 de descarga soportará Mercurial. Si habilita esta característica,
940 los usuarios de la interfaz web podrán descargar una copia de la
941 revisión del repositorio que estén viendo. Para activar la
942 característica de descarga de fichero, el valor tendrá una secuencia
943 de palabras extraídas de la lista de abajo.
944 \begin{itemize}
945 \item[\texttt{bz2}] Un fichero \command{tar} con el método de
946 compresión \texttt{bzip2}. Tiene la mejor tasa de compresión,
947 pero usa más tiempo de procesamiento en el servidor.
948 \item[\texttt{gz}] Un fichero \command{tar}, comprimido con
949 \texttt{gzip}.
950 \item[\texttt{zip}] Un fichero \command{zip}, comprimido con LZW.
951 Este formato posee la peor tasa de compresión, pero es muy usado en
952 el mundo Windows.
953 \end{itemize}
954 Si da una lista vacía o no tiene la entrada
955 \rcitem{web}{allow\_archive}, esta característica se deshabilitará.
956 A continuación un ejemplo de cómo habilitar los tres formatos soportados.
957 \begin{codesample4}
958 [web]
959 allow_archive = bz2 gz zip
960 \end{codesample4}
961 \item[\rcitem{web}{allowpull}] Booleano. Determina si la interfaz web
962 permite a los usuarios remotos emplear \hgcmd{pull} y \hgcmd{clone}
963 sobre el repositorio~HTTP. Si se coloca \texttt{no} o
964 \texttt{false}, solamente la porción de los procesos
965 ``orientados-a-humanos'' se habilita de la interfaz web.
966 \item[\rcitem{web}{contact}] Cadena. Una cadena en forma libre (pero
967 preferiblemente corta) que identifica a la persona o grupo a cargo
968 del repositorio. Usualmente contiene el nombre y la dirección de
969 correo electrónico de una persona o de una lista de correo. Aveces
970 tiene sentido colocar esta opción en el fichero \sfilename{.hg/hgrc}
971 del repositorio, pero en otras oportunidades en el \hgrc\ global si
972 todos los repositorios tienen un único mantenedor.
973 \item[\rcitem{web}{maxchanges}] Entero. La cantidad máxima de
974 conjuntos de cambios a mostrar de forma predeterminada en cada página.
975 \item[\rcitem{web}{maxfiles}] Entero. La cantidad máxima
976 predeterminada de ficheros modificados a desplegar en una página.
977 \item[\rcitem{web}{stripes}] Entero. Si la interfaz web despliega
978 ``franjas'' para facilitar la visualización alineada de filas cuando
979 se ve una tabla, este valor controla la cantidad de filas en cada
980 franja.
981 \item[\rcitem{web}{style}] Controla la plantilla que Mercurial usa para
982 desplegar la interfaz web. Mercurial viene con dos plantillas web,
983 llamadas \texttt{default} y \texttt{gitweb} (La primera es
984 visualmente más atractiva). Puede especificar una plantilla propia;
985 consulte el capítulo~\ref{chap:template}. A continuación mostramos
986 cómo habilitar el estilo \texttt{gitweb}.
987 \begin{codesample4}
988 [web]
989 style = gitweb
990 \end{codesample4}
991 \item[\rcitem{web}{templates}] Ruta. Directorio en el que se buscarán
992 los ficheros plantilla. De forma predeterminada, busca en el
993 directorio en el cual fue instalado.
994 \end{itemize}
995 Si usa \sfilename{hgwebdir.cgi}, puede añadir otras opciones de
996 configuración en una sección \section{web} del fichero
997 \sfilename{hgweb.config} en lugar del fichero \hgrc\, si lo considera
998 más conveniente. Estas opciones son \rcitem{web}{motd} y
999 \rcitem{web}{style}.
1001 \subsubsection{Opciones específicas para repositorios individuales}
1003 Ciertas opciones de configuración de \rcsection{web} deben estar
1004 ubicadas en el \sfilename{.hg/hgrc} de un repositorio en lugar del
1005 fichero del usuario o el \hgrc global.
1006 \begin{itemize}
1007 \item[\rcitem{web}{description}] Cadena. Una cadena de forma
1008 libre (preferiblemente corta) que describa los contenidos o el
1009 propósito del repositorio.
1010 \item[\rcitem{web}{name}] Cadena. El nombre para visualizar en la
1011 interfaz web del repositorio. Sustituye el nombre predeterminado, el
1012 cual es el último componente de la ruta del repositorio.
1013 \end{itemize}
1015 \subsubsection{Opciones específicas a la orden \hgcmd{serve}}
1017 Algunas opciones en la sección \rcsection{web} de un fichero \hgrc\
1018 son de uso exclusivo para la orden \hgcmd{serve}.
1019 \begin{itemize}
1020 \item[\rcitem{web}{accesslog}] Ruta. El nombre del fichero en el cual
1021 se escribe la bitácora de acceso. En principio, la orden
1022 \hgcmd{serve} escribe esta información a la salida estándar, no a un
1023 fichero. Las líneas de la bitácora se escriben en un formato de
1024 fichero ``combinado'' estándar, usado por casi todos los servidores
1025 web.
1026 \item[\rcitem{web}{address}] Cadena. La dirección local en la cual el
1027 servidor debe escuchar peticiones entrantes. En principio, el
1028 servidor escucha en todas las direcciones.
1029 \item[\rcitem{web}{errorlog}] Ruta. El nombre de un fichero en el
1030 cual escribir la bitácora de error. En principio, la orden
1031 \hgcmd{serve} escribe esta información en la salida de error
1032 estándar, no a un fichero.
1033 \item[\rcitem{web}{ipv6}] Booleano. Si se usa o no el protocolo
1034 IPv6. En principio, IPv6 no se usa.
1035 \item[\rcitem{web}{port}] Entero. El número del puerto~TCP en el cuál
1036 el servidor escuchará. El puerto predeterminado es el~8000.
1037 \end{itemize}
1039 \subsubsection{Elegir el fichero \hgrc\ correcto para las
1040 configuraciones de \rcsection{web}}
1042 Es importante recordar que un servidor web como Apache o
1043 \texttt{lighttpd} se ejecutarán bajo el usuario~ID que generalmente no
1044 es el suyo Los guiones CGI ejecutados por su servidor, tales como
1045 \sfilename{hgweb.cgi}, se ejecutarán también con el usuario~ID.
1047 Si añade opciones \rcsection{web} a su fichero personal \hgrc\, Los
1048 guiones CGI no leerán tal fichero \hgrc\. Tales configuraciones
1049 solamente afectarán el comportamiento de la orden \hgcmd{serve} cuando
1050 usted lo ejecuta. Para logar que los guiones CGI vean sus
1051 configuraciones, o bien cree un fichero \hgrc\ en el directorio hogar
1052 del usuario ID que ejecuta su servidor web, o añada tales
1053 configuraciones al fichero global \hgrc.
1056 %%% Local Variables:
1057 %%% mode: latex
1058 %%% TeX-master: "00book"
1059 %%% End: