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