Un sistema de control de versiones (o sistema de control de revisiones) es una combinaci�n de tecnolog�as y practicas para seguir y controlar los cambios realizados en los ficheros del proyecto, en particular en el c�digo fuente, en la documentaci�n y en las p�ginas web. Si nunca antes se ha utilizado un control de versiones, lo primero que hay que hacer es conseguir a alguien que s� lo haya hecho y hacer que se una al proyecto. Hoy en d�a todo el mundo espera que al menos el c�digo fuente del proyecto este bajo un control de versiones y probablemente no se tomen el proyecto seriamente si no se utiliza este sistema con un m�nimo de competencia.
La raz�n por la cual el control de versiones es universal es porque ayuda virtualmente en todos los aspectos al dirigir un proyecto: comunicaci�n entre los desarrolladores, manejo de los lanzamientos, administraci�n de fallos, estabilidad entre el c�digo y los esfuerzos de desarrollo experimental y atribuci�n y autorizaci�n en los cambios de los desarrolladores. El sistema de control de versiones permite a una fuerza coordinadora central abarcar todas estas �reas. El n�cleo del sistema es la gesti�n de cambios: identificar cada cambio a los ficheros del proyecto, anotar cada cambio con meta-data como la fecha y el autor de la modificaci�n y disponer esta informaci�n para quien sea y como sea. Es un mecanismo de comunicaci�n donde el cambio es la unidad b�sica de informaci�n.
Aun no hemos discutido todos los aspectos de utilizar un sistema de control de versiones ya que es un tema tan extenso que ser� introducido seg�n el t�pico a lo largo de este libro. Ahora, vamos a concentrarnos en seleccionar y configurar un sistema de control de versiones de forma que fomentemos un desarrollo cooperativo.
En este libro no podemos ense�ar como utilizar el control de versiones si nunca antes lo ha utilizado, pero ser�a imposible continuar sin conocer algunos t�rminos clave. Estos son �tiles independientemente del sistema particular utilizado: son definiciones b�sicas y verbos sobre la colaboraci�n en red y ser�n utilizados a lo largo del libro. Incluso si no existiera ning�n sistema de control de versiones, el problema del control de los cambios aun existir�a y estas palabras nos dan un lenguaje para hablar acerca de este problema consistentemente.
Realizar un cambio en el proyecto. Formalmente, almacenar un cambio en la base de datos del control de versiones de forma que pueda ser incorporado en lanzamientos futuros del proyecto. "Commit" puede ser utilizado como un verbo o como un sustantivo. Como un sustantivo, es esencialmente un sin�nimo de "cambio". Por ejemplo: "He commited una reparaci�n para un fallo reportado en Mac OS X que hacia que el servidor se colgara. J�se �podr�as por favor revisarlo y verificar que no estoy haciendo mal la asignaci�n?"
Solicitar los cambios (commits) que han realizado otros en la copia local del proyecto, esto actualiza esta copia a la ultima versi�n. Es una operaci�n muy com�n ya que la mayor�a de los desarrolladores actualizan su c�digo varias veces al d�a y as� saben que est�n ejecutando casi lo mismo que los otros desarrolladores, as� que si se descubre un fallo es muy posible que este aun no haya sido resuelto. Por ejemplo: "Hey, he notado que el c�digo del �ndice est� fallando en el �ltimo byte. �Es esto un nuevo fallo?" "S�, pero fue resuelto la semana pasada—prueba actualizar para resolverlo."
Un peque�o comentario a�adido a cada commit que describe el tipo y el prop�sito del commit. Los mensajes de registro forman parte de los documentos m�s importantes de cualquier proyecto ya que son un puente entre el lenguaje altamente t�cnico de los cambios individuales en el c�digo y el lenguaje m�s orientado al usuario de caracter�sticas, resoluci�n de fallos y progreso del proyecto. M�s adelante vamos a ver la forma de distribuir estos mensajes a la audiencia apropiada y tambi�n “Tradici�n en la organizaci�n del contenido” en Cap�tulo�6, Comunicaciones discutimos como ENCOURAGE a los voluntarios para que escriban mensajes de registro �tiles y concisos.
Una base de datos en la que los cambios son almacenados. Algunas versiones de sistemas de control de versiones son centralizados, es decir, existe un �nico repositorio maestro, el cual almacena todos los cambios en el proyecto. Otros sistemas son descentralizados, cada desarrollador tiene su propio repositorio y los cambios pueden ser intercambiados entre repositorios arbitrariamente. El sistema de control de versiones mantiene un registro de las dependencias entre estos cambios y cuando llega el momento de realizar un lanzamiento, un conjunto particular de cambios es aprobado para ese lanzamiento. La cuesti�n de cual sistema es mejor es otra de las guerras santas del desarrollo de software. Intentad no caer en la trampa de discutir sobre esto en las listas de correo del proyecto.
El proceso de obtener una copia del proyecto desde el repositorio. Por lo general, un checkout produce un �rbol de directorios llamado "copia funcional" desde el cual los cambios ser�n enviados de vuelta al repositorio original. En algunas versiones descentralizadas de sistemas de control, cada copia funcional es en si mismo un repositorio y los cambios son empujados (o atra�dos) a cualquier repositorio que este dispuesto a aceptarlos.
El �rbol de directorios privado de cada desarrollador que que contiene el c�digo fuente del proyecto y posiblemente las p�ginas web u otros documentos. Una copia funcional tambi�n contiene un peque�a cantidad de meta-data administrada por el sistema de control de versiones, informando a la copia funcional cual es repositorio central de procedencia, la revisi�n de los ficheros presentes, etc. Generalmente, cada desarrollador tiene su propia copia funciona en la cual realiza y prueba los cambios y desde la cual env�a sus commits (cambios).
Una revisi�n es usualmente una encarnaci�n espec�fica de un fichero o directorio en particular. Por ejemplo, si el proyecto se inicia en la revisi�n 6 del fichero F y alguien env�a un cambio al fichero F, esto produce la revisi�n 7 de F. Algunos sistemas tambi�n utilizan revisi�n (revision), cambio (change) o conjunto de cambios (changeset) para referirse a un conjunto de cambios enviados juntos como una unidad conceptual.
Estos conceptos pueden tener distintos significados t�cnicos en cada sistema de control de versiones, pero en general, la idea es siempre la misma: dar un sistema para comunicar de manera precisa la historia de cambios en un fichero o conjunto de ficheros (inmediatamente antes y despu�s de que se ha corregido un fallo). Por ejemplo: "Eso se ha resuelto en la revisi�n 10" o "Se ha corregido eso en la revisi�n 10 del fichero foo.c."
Cuando se habla sobre ficheros o una colecci�n de ficheros sin especificar una revisi�n en particular, por lo general se asume que nos referimos a la revisi�n disponible m�s reciente.
Una representaci�n contextual de un cambio. Un diff muestra las lineas que han sido modificadas, como y adem�s, algunas lineas contextuales rode�ndolas a cada lado. Un desarrollador familiarizado con el c�digo puede, con leer un diff de ese c�digo, entender lo que hace el cambio e incluso detectar fallos.
Una etiqueta para una colecci�n particular de ficheros en una revisi�n
espec�fica. Los tags son utilizados para preservar capturas interesantes
del proyecto. Por ejemplo, un tag es hecho para cada lanzamiento p�blico,
de forma que cada persona pueda obtener, directamente desde el sistema
de control de versiones, el conjunto exacto de ficheros/revisiones
que componen el lanzamiento. Algunos tags comunes son como
Release_1_0, Delivery_00456,
etc.
Es una copia del proyecto, bajo el control de versiones, pero aislado, de forma que los cambios realizados en esta rama no afecten al resto del proyecto y vice versa, excepto cuando los cambios sean deliberadamente "unidos" de un lado al otro. Las ramas tambi�n son conocidas como "lineas de desarrollo". Incluso cuando un proyecto no tiene ramas espec�ficas se considera que el desarrollo se esta produciendo en la rama principal, tambi�n conocida como "l�nea primaria" o "trunk".
Las ramas o branches, permiten aislar diferentes lineas de desarrollo de si mismas. Por ejemplo, una rama puede ser utilizada para un desarrollo experimental que ser�a demasiado inestable para la rama principal. O al contrario, una rama puede ser utilizada como sitio para estabilizar una versi�n para lanzamiento. Durante el proceso de lanzamiento, el desarrollo regular se mantendr�a ininterrumpida en la rama principal. Mientras tanto, en la rama de lanzamiento, ning�n cambio es aceptado excepto aquellos aprobados por el responsable del lanzamiento. De esta manera, realizar un lanzamiento no tiene porque interferir con el trabajo de desarrollo que se est� realizando. Para m�s informaci�n “Las ramas para evitar cuellos de botella” m�s adelante en el cap�tulo para una discusi�n m�s detallada sobre las ramas.
Mover un cambio de una rama a otra, lo que incluye unir desde la rama principal a otra rama o vice versa. De hecho, estos son las uniones m�s comunes y es rara la ocasi�n en la que esto se hace entre dos ramas no principales. Para m�s informaci�n sobre los merge “Singularidad de la informaci�n”.
"Merge" tiene otro significado: es lo que hace el sistema de control de versiones cuando se encuentra con que dos personas han realizado cambios en un mismo fichero sin relaci�n alguna. Ya que estos cambios no interfieren entre ellos, cuando alguna de estas personas actualizan su copia del fichero (el cual ya contiene los cambios) los cambios de la otra persona ser�n unidos autom�ticamente. Esto sucede muy a menudo, especialmente en proyectos con m�ltiples personas realizando cambios en el mismo c�digo. Cuando dos cambios diferentes est�n relacionados, el resultado es un "conflicto".
Sucede cuando dos o m�s personas intentan realizar diferentes cambios en la misma porci�n de c�digo. Todos los sistemas de control de versiones detectan estos conflictos autom�ticamente y notifican a al menos uno de los humanos involucrados de que sus cambios entran en conflicto con los de alguien m�s. Es entonces tarea de esta personas resolver el conflicto y comunicar esa resoluci�n al sistema de control de versiones.
Declaraci�n de un intento exclusivo para cambiar un fichero o directorio en particular. Por ejemplo, "No puedo enviar cambios a las paginas web ahora mismo, ya que parece que Alfredo las tiene bloqueadas mientras arregla sus im�genes de fondo." No todos los sistemas de control de versiones ofrecen la posibilidad del bloqueo y aquellos que s� lo permiten, no es necesario que se utilice. Esto es porque el desarrollo paralelo y simultaneo es la norma y bloquear a la gente para que no puedan modificar los ficheros es contrario a la idea del sistema.
El modelo del sistema de control de versiones que requiere el bloqueo de ficheros suele ser llamado bloqueo-modificaci�n-desbloqueo y el modelo que no requiere del bloqueo es llamado copia-modificaci�n-uni�n. Una excelente explicaci�n en profundidad y comparaciones puede ser encontrada en http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html. En general, el modelo de copia-modificaci�n-uni�n es el mejor para el desarrollo open source y todos los sistemas de control de versiones discutidos en este libro soportan este modelo.
Las recomendaciones realizadas en esta secci�n no est�n enfocadas hacia un sistema de control de versiones en particular y deber�a ser sencillo implementarlas en cualquiera. La documentaci�n espec�fica del sistema debe ofrecer los detalles necesarios.
No solo hay que mantener el c�digo del proyecto bajo el control de versiones tambi�n las paginas web, documentaci�n, FAQ, notas de dise�o y cualquier cosa que pueda ser necesario editar. Todo esto hay que mantenerlo cerca del c�digo, en el mismo �rbol que el repositorio. Se deben mantener versiones de cualquier pieza de informaci�n que pueda cambiar y archivar la que no cambie. Por ejemplo, un correo electr�nico, una vez enviado, no cambia, por lo tanto, mantener versiones de este no tiene sentido (a menos que se convierta en una parte importante de la documentaci�n).
La raz�n de mantener versiones de todo en un mismo sitio, es para que la gente s�lo tenga que aprender un sistema para realizar cambios. A menudo, un voluntario se iniciara modificando algunas paginas web o partes de la documentaci�n, para luego pasar a realizar peque�as contribuciones al c�digo, por ejemplo. Cuando el proyecto utiliza el mismo sistema para todo tipo de cambios, las personas s�lo tendr�n que aprender THE ROPES una vez. Mantener las versiones juntas significa que nuevas caracter�sticas pueden ser a�adidas junto a la actualizaci�n de la documentaci�n, y que al crear ramas del c�digo, se crearan ramas de la documentaci�n, etc.
No hace falta mantener los ficheros generados
bajo el sistema de control de versiones ya que no son datos editables
generados por otros programas. Por ejemplo, algunos sistemas de
compilado generan los ficheros configure basandose
en una plantilla configure.in. Para realizar
cambios al fichero configure bastar�a con
modificar configure.in y volver a generarlo.
Entonces, s�lo el fichero configure.in es
un fichero editable. S�lo es necesario mantener versiones de las
plantillas—si se hace con los ficheros generados, la gente
se olvidar� de volver a generarlos cuando realicen alg�n cambio
en las plantillas y las resultantes inconsistencias crearan una
mayor confusi�n. [30]
La regla de que todos los datos editables deben ser mantenidos bajo el control de versiones tiene una excepci�n desafortunada: el gestor de fallos. La base de datos de fallos almacena una gran cantidad de datos editables pero generalmente, por razones t�cnicas, no se puede mantener bajo el control de versiones principal. (Algunos gestores tienen caracter�sticas primitivas de control de versiones, pero independiente de repositorio principal del proyecto.)
El repositorio del proyecto debe ser accesible desde Internet. Esto no solo significa la habilidad de visualizar la ultima revisi�n de los ficheros del proyecto, pero permitir volver atr�s en el tiempo y ver en revisiones anteriores, mirar las diferencias entre revisiones, leer los mensajes de registro para cambios espec�ficos, etc.
La navegabilidad es importante porque es un ligero portal a los datos del proyecto. Si el repositorio no es accesible desde un navegador web entonces alguien que desea inspeccionar un fichero en particular (por ejemplo, para mirar si una mejora ha sido incluida en el c�digo) tendr� que instalar el mismo programa utilizado por el sistema de control de versiones, lo cual convierte una simple consulta de dos minutos en una tarea de medio hora o m�s.
Tambi�n implica URLs CANONICAL para visualizar revisiones
espec�ficas de un fichero y para la ultima revisi�n en cualquier
momento. Esto puede ser muy �til durante discusiones t�cnicas o para
indicar alguna documentaci�n a la gente. Por ejemplo, en lugar de
decir "Para ayudas sobre como encontrar fallos en el servidor,
mirad el fichero www/hacking.html en vuestra copia funcional" se puede
decir "Para ayudas sobre como encontrar fallos en el servidor,
mirad http://subversion.apache.org/docs/community-guide/,"
dando una URL que siempre lleva a la ultima revisi�n del fichero
hacking.html. La URL es mejor porque no es nada
ambigua y evita la cuesti�n de si existe una copia funcional
actualizada.
Algunos sistemas de control de versiones incluyen un mecanismo que permite la navegaci�n del repositorio, mientras que otros dependen de herramientas de terceros. Tres de estas herramientas son ViewCVS (http://viewcvs.sourceforge.net/), CVSWeb (http://www.freebsd.org/projects/cvsweb.html), and WebSVN (http://websvn.tigris.org/). La primera trabaja muy bien con CVS y con Subversion, la segunda s�lo con CVS y la tercera s�lo con Subversion.
Los usuarios inexpertos del control de versiones pueden sentirse temerosos de crear ramas y uniones. Esto sea probablemente un efecto colateral de la popularidad de CVS: su interfaz de ramas y uniones puede ser poco intuitivo, as� que muchas personas han aprendido a evitar estas operaciones por completo.
Si se encuentra entre estas personas, decidase ahora mismo a conquistar cualquier miedo que pueda tener y t�mese el tiempo de aprender c�mo funcionan las ramas y las uniones. No son operaciones muy complicadas una vez que se acostumbra a ellas y se vuelven muy importantes mientras el proyecto adquiere m�s desarrolladores.
Las ramas son muy importantes porque convierten un recurso escaso—espacio de trabajo en el c�digo del proyecto—en uno abundante. Normalmente, todos los desarrolladores trabajan juntos en la misma caja de arena, construyendo el mismo castillo. Cuando alguien desea a�adir un nuevo puente levadizo, pero no puede convencer a los dem�s de que ser�a una mejora, entonces las ramas hacen posible que vaya a una esquina aislada donde probar su puente. Si el esfuerzo tiene �xito, puede invitar a otros desarrolladores para que eval�en el resultado. Si todos est�n de acuerdo en que el resultado es bueno, pueden hacer que el sistema de control de versiones mueva ("merge") el puente levadizo de la rama del castillo a la rama principal del castillo.
Es f�cil ver como esta habilidad ayuda al desarrollo colaborativo, ya que la gente necesita de cierta libertad para probar cosas nuevas sin sentir que est�n interfiriendo con el trabajo de otros. Igual de importante es cuando el c�digo debe ser aislado del CHURN usual de desarrollo de manera que un fallo sea reparado o un lanzamiento sea estabilizado (m�s en “Stabilizing a Release” y en “Maintaining Multiple Release Lines” en Cap�tulo�7, Empaquetado, Liberaci�n, y Desarrollo diario) sin la preocupaci�n de seguir un blanco en movimiento.
Hay que utilizar las ramas libremente y fomentar su uso entre otros. Pero tambi�n hay que asegurarse de que una rama en particular se mantenga activa exactamente durante el tiempo que sea necesaria. Incluso quienes no trabajan en la rama principal mantienen una visi�n perif�rica de lo que est� sucediendo en �sta. Esta visi�n es deseable, por supuesto, y los correos con cambios deben salir de estas ramas como de cualquier otra. Pero las ramas no deben convertirse en un mecanismo que divida a la comunidad de desarrolladores. Con raras excepciones, el objetivo eventual de la mayor�a de las ramas debe de ser su uni�n a la rama principal y desaparecer.
Las uniones tienen un corolario importante: nunca se debe enviar el mismo cambio dos veces, es decir, un cambio dado s�lo debe ser introducido al sistema de control de versiones solo una vez. La revisi�n (o conjunto de revisiones) en la que el cambio es introducido es su identificador �nico desde ese momento. Si debe ser aplicado a otras ramas aparte de la cual en la que ha sido hecho, entonces deber� ser unido desde su punto de entrada original a sus otros destinos —al contrario de enviar cambios textualmente id�nticos, que tendr�an el mismo efecto en el c�digo, pero har�an del mantenimiento eficaz y de la gesti�n de lanzamientos una tarea imposible.
Los efectos pr�cticos de este consejo difieren entre sistemas de control de versiones. En algunos sistemas, las uniones son eventos especiales, fundamentalmente distintos de los commits y acarrean sus meta-datos propios. En otros, el resultado de las uniones son enviadas de la misma manera que los cambios son enviados as� que la mejor manera de distinguir una uni�n de un nuevo cambio es leyendo los mensajes de registro. El mensaje de registro de una uni�n no repite el mensaje de registro del cambio original, en cambio, s�lo indica que es una uni�n y da la identificaci�n de la revisi�n del cambio original, con como mucho una l�nea de sumario del sus efectos. Si alguien desea ver el mensaje de registro completo, deber� consultar la revisi�n original.
La raz�n por la cual es importante evitar la repetici�n de los mensajes de registro es que estos pueden ser editados despu�s de que se hayan enviado. Si un mensaje de registro es repetido en el destino de cada uni�n, entonces incluso si alguien edita el mensaje original, deja todos los otros mensajes sin corregir—lo cual s�lo puede causar confusi�n a largo plazo.
El mismo principio se aplica al retirar un cambio. Si esto llegara a suceder, entonces el mensaje de registro para la retirada solo debe indicar que una revisi�n en particular est� siendo retirada, no debe describir el cambio en el c�digo resultante, pues la sem�ntica del cambio se puede intuir al leer el mensaje de registro original del cambio. Por supuesto, el mensaje de registro del retiro tambi�n debe indicar la raz�n por la cual ese cambio ha sido retirado, pero no debe duplicar nada del mensaje de registro del cambio original. Si es posible, hay que volver y editar el mensaje de registro original para se�alar que ha sido retirado.
Todo lo anterior implica que se debe utilizar una sintaxis
consistente al referirnos a las revisiones. Esto es de gran ayuda
no s�lo en los mensajes de registro, sino en los correos electr�nicos,
en el gestor de fallos y en todas partes. Si se esta utilizando
CVS, recomiendo "directorio/al/fichero/del/proyecto/rama:REV",
donde REV es un n�mero de revisi�n en CVS como "1.76". Si se esta
utilizando Subversion, la sintaxis est�ndar para la revisi�n
1729 es "r1729" (el directorio de los ficheros no es necesario
porque Subversion utiliza n�meros globales para las revisiones). En
otros sistemas, existe por lo general una sintaxis est�ndar para
expresar el nombre del conjunto de cambios. Cualquiera que sea
la sintaxis apropiada para el sistema utilizado, hay que animar
a la gente a que lo utilicen al referirse a alg�n cambio. El
uso consistente en el nombre de los cambios permiten que el
mantenimiento del proyecto sea mucho m�s sencillo (como ya
veremos en Cap�tulo�6, Comunicaciones y en
Cap�tulo�7, Empaquetado, Liberaci�n, y Desarrollo diario), y dado que mucho de este
mantenimiento ser� realizado por voluntarios, debe ser lo m�s
sencillo posible.
M�s informaci�n en “Releases and Daily Development” Cap�tulo�7, Empaquetado, Liberaci�n, y Desarrollo diario.
Muchos de los sistemas de control de versiones ofrecen la posibilidad por la cual a ciertas personas se les permite o no, realizar cambios en �reas espec�ficas del repositorio. Siguiendo el principio de que cuando a las personas se les entrega un martillo empiezan a buscar clavos para golpear, muchos proyectos utilizan esta caracter�stica con ABANDON, permitiendo cuidadosamente el acceso solo a las �reas donde tienen permiso de enviar cambio y asegur�ndose de que no lo puedan hacer en ning�n otro sitio. (M�s informaci�n en “Committers” Cap�tulo�8, Coordinando a los Voluntarios sobre como los proyectos deciden quienes pueden hacer cambios y donde.)
Probablemente hayan peque�os da�os implementar un control as� de estricto, pero una pol�tica un poco m�s relajada tambi�n esta bien. Algunos proyectos utilizan un sistema basado en el honor: cuando a una persona se le permite la posibilidad de realizar cambios, aunque sea a una peque�a �rea del repositorio, lo que reciben es una contrase�a que les permite realizar cambios en cualquier otro sitio del repositorio y s�lo se les pide que mantengan sus cambios en su �rea. Hay que recordar que no existe ning�n peligro aqu�: de todas formas, en un proyecto activo, todos los cambios son revisados. Si alguien hace un cambio donde no deb�a, alguien m�s se dar� cuenta y dir� algo. Es muy sencillo si un cambio debe ser rectificado—todo est� bajo el control de versiones de todas formas, as� que s�lo hay que volver atras.
Existen varias ventajas en tal aproximaci�n tan relajada. Primero, mientras los desarrolladores se vayan expandiendo en las diferentes �reas (lo cual har�n a menudo si siguen en el proyecto), no es necesario un trabajo administrativo extra de tener que dar y quitar privilegios. Una vez que la decisi�n es tomada, la persona puede empezar a enviar sus cambios a la nueva �rea sin problemas.
Segundo, la expansi�n se puede filtrar mejor, ya que generalmente, quienes realizan cambios en el �rea X y desean expandirse al �rea Y s�lo tienen que empezar a enviar sus cambios contra Y y solicitar su revisi�n. Si alguien con acceso a cambios al �rea Y recibe alguno de estos parches y lo aprueba, puede pedir que el cambio sea enviado directamente (mencionando el nombre de quien ha revisado/aprobado el cambio en el mensaje de registro). De esta manera, el commit vendr� de quien ha hecho el cambio, lo cual es preferible desde un punto de vista administrativo y de credibilidad.
Por �ltimo, y quiz�s la raz�n m�s importante, al utilizar un sistema basado en el honor, se crea una atm�sfera de confianza y respeto mutuo. Al darle a alguien permiso para enviar cambio a un subdominio se hace una declaraci�n acerca de su preparaci�n t�cnica—la cual dice: "Hemos visto que tienes la capacidad para realizar cambios en cierto dominio, as� que a por ello". Pero imponer controles estrictos en las autorizaciones dice: "No s�lo estamos juzgando tus limitadas capacidades, sino que tambi�n sospechamos de tus intenciones." Este no es el tipo de declaraciones que se desean hacer si pueden ser evitadas. Incluir a alguien dentro del grupo de desarrolladores del proyecto es una oportunidad de iniciarlos en un circulo de confianza mutua. Una buena manera de hacer esto es dar m�s poder del que se supone deben tener e informarles que es su responsabilidad mantenerse dentro de los l�mites impuestos.
El proyecto Subversion ha operado bajo este sistema por m�s de cuatro a�os, con 33 desarrolladores con privilegios completos y 43 con privilegios parciales. La �nica distinci�n que el sistema fuerza esta entre quienes env�an cambios y quienes no, otras divisiones son mantenidas s�lo por humanos. Incluso as�, nunca hemos tenido ning�n problema con que alguien realice un cambio deliberado fuera de su dominio. Una que otra vez han habido inocentes mal entendidos sobre la extensi�n de los privilegios de alguna persona, pero siempre es resuelto r�pida y amigablemente.
Obviamente, en situaciones donde esto es poco pr�ctico se debe depender en controles estrictos en las autorizaciones, pero dadas situaciones son raras. Incluso cuando hay millones de lineas de c�digo y ciento o miles de desarrolladores, un commit hecho a cualquier m�dulo del c�digo sigue siendo revisado por quienes trabajan en dicho m�dulo y son quienes pueden reconocer si quien lo ha intentado hacer puede hacerlo. Si una revisi�n regular no est� sucediendo entonces el proyecto tiene problemas m�s importantes con los cuales lidiar que el sistema de autorizaciones.
Para concluir, no hace falta pasar mucho tiempo con las autorizaciones del sistema de control de versiones a menos que se tenga una raz�n en espec�fico. Usualmente esto no trae beneficios tangibles y confiar en el control humano tiene sus ventajas.
Por supuesto que nada de esto significa que las restricciones mismas son poco importantes. Ser�a malo para un proyecto el animar a las personas a realizar cambios en �reas para las cuales no est�n cualificadas. Incluso en algunos proyectos, el acceso ilimitado tiene un status especial: implica derecho de voto en cuestiones que ata�en al proyecto por completo. Este aspecto pol�tico del acceso es discutido en mayor profundidad en “�Qui�n Vota?” en Cap�tulo�4, Infraestructura Social y Pol�tica.
Cada commit al repositorio deber�a generar un correo electr�nico mostrando quien ha hecho el cambio, cuando, cuales ficheros y directorios han cambiado y como. Este correo debe ser dirigido a una lista de correos separada de las listas a las que env�an los humanos. Los desarrolladores y todos aquellos interesados deben ser animados para suscribirse a las lista de commits ya que es la manera m�s efectiva de mantenerse al d�a con lo que sucede en el proyecto al nivel del c�digo. Aparte de los obvios beneficios t�cnicos de la revisi�n por la comunidad (“Practicar Revisiones Visibles del C�digo”), los correos con los cambios ayudan a crear un sentido de comunidad porque establecen un ambiente compartido en el que la gente puede reaccionar ante diferentes eventos (commits) que saben son visibles a otros tambien.
La configuraci�n espec�fica para habilitar estos correos varia dependiendo de la versi�n del sistema de control de versiones pero a menudo existe un script o paquete que facilita esto. Si se tiene alg�n problema para encontrar estos, intente buscar en la documentaci�n el tema relacionado con los hooks, espec�ficamente el post-commit hook, tambi�n llamado loginfo hook en CVS. Los Post-commit hooks son tareas automatizadas que se ejecutan como respuesta a los cambios enviados (commits). El hook es ejecutado por un cambio individual, se rellena con la informaci�n acerca del cambio y luego es liberada esa informaci�n para ser utilizada como se desee—por ejemplo, para enviar un correo electr�nico.
Con los sistemas de correos con cambios ya listos para usar, quiz�s sea necesario modificar alguna de las siguientes conductas:
Algunos de estos sistemas no incluyen el diff en el correo que env�an sino que enlazan con una URL para poder ver el cambio en la web utilizando el sistema de navegaci�n del repositorio. Aunque esta bien dar una URL para que se pueda revisar el cambio luego, tambi�n es muy importante que el correo del commit incluya los diff. Leer el correo electr�nico ya es parte de la rutina de la gente, as� que si el contenido es visible all� mismo en el correo, los desarrolladores podr�n revisar el commit en el mismo sitio sin la necesidad de abandonar sus clientes de correo. Si tienen que seguir un enlace a una p�gina de revisiones, muchos no lo pulsar�n, ya que esto requiere de una nueva acci�n en lugar de una continuaci�n de lo que ya estaban haciendo. Por si fuera poco, si el lector desea preguntar algo acerca del cambio, es mucho m�s f�cil responder al mensaje incluyendo el texto original y simplemente realizar anotaciones en el diff, en lugar de tener que visitar una p�gina web y tomarse la molestia de copiar y pegar partes del diff en el navegador web al cliente de correo.
(Por supuesto que si el diff es gigantesco, como cuando una gran parte de c�digo nuevo ha sido a�adido al repositorio, entonces tiene sentido omitir la parte del diff y ofrecer s�lo la URL. Muchos de los sistemas permiten hacen esto autom�ticamente. Si el utilizado en el proyecto no es capaz de hacer esto, entonces sigue siendo mejor incluir los diffs completos. La conveniencia de la revisi�n y los comentarios es una piedra angular del desarrollo cooperativo, algo demasiado importante para olvidar.)
Los correos con los cambios deben tener su cabecera Reply-To direccionada hacia la lista regular de desarrollo, no a la lista de los cambios, de esta manera cuando alguien revise un cambio y escriba una respuesta, esta debe ser dirigida autom�ticamente a la lista de desarrolladores, donde los temas t�cnicos son discutidos normalmente. Existen varias razones para esto, primero, se quiere mantener todas las discusiones t�cnicas en la lista, porque es all� donde la gente espera que sucedan y porque as� �sta es la �nica lista que ser� necesario archivar. Segundo, puede que existan partes interesadas no suscritas a la lista de cambios. Tercero, la lista de cambios es publicitada como una lista para los commits y no como una lista para los commits y las discusiones t�cnicas ocasionadas. Quienes se han suscrito s�lo a la lista de cambios, no se han suscrito a nada m�s que commits, al enviarles correos con material sin relaci�n utilizando �sta v�a, es una violaci�n del contrato impl�cito. Cuarto, algunas personas escriben programas que procesan los correos con los cambios (para publicarlos en una p�gina web, por ejemplo). Estos programas est�n preparados para manejar correos con un formato consistente y son incapaces de trabajar con correos escritos por humanos.
Hay que se�alar que �sta recomendaci�n no contradice las recomendaciones anteriores en “El gran debate del Reply-To”. Siempre esta bien que el remitente del mensaje configure la cabecera Reply-to. En este caso, el remitente es el sistema de control de versiones y su Reply-to lo configura de tal manera que indique que el lugar apropiado para responder es la lista de desarrollo y no la lista de cambios
[30] Alexey Mathotkin tiene una
opini�n diferente sobre el tema de controlar las versiones de los
ficheros configure en un art�culo llamado
"configure.in and version control" en
http://versioncontrolblog.com/2007/01/08/configurein-and-version-control/.