El primer paso para participar en la comunidad es encontrar un modo de estar al día de los últimos eventos. Para hacer esto de la manera más efectiva, querrá apuntarse a la lista principal de discusión de desarrolladores (<dev@subversion.tigris.org>) y la lista de cambios enviados al servidor (<svn@subversion.tigris.org>). Siguiendo estas listas incluso desde lejos, tendrá acceso a importantes discusiones de diseño, será capaz de ver los cambios en el código de Subversion a medida que ocurren, y presenciar revisiones de otras personas de esos cambios y propuestos cambios. Estas listas de discusión basadas en email son el medio de comunicación principal para el desarrollo de Subversion. Vea la sección de listas de correo en la página web para ver otras listas relacionadas con Subversion en las que pueda estar interesado.

¿Pero cómo puede saber qué es lo que debe hacerse? Es bastante habitual para un programador tener la mejor de las intenciones de ayudar con el desarrollo, pero ser incapaz de encontrar un buen punto de partida. Después de todo, no todas las personas vienen a la comunidad habiendo decidido qué detalle en particular quieren modificar. Pero observando las listas de discusión de los desarrolladores, puede llegar a ver mencionados fallos existentes o peticiones relacionadas con algo que le interese particularmente. También, otro buen lugar para buscar tareas pendientes no asignadas es la base de datos de tareas en la página web de Subversion. Ahí encontrará una lista actualizada de fallos conocidos y peticiones de características. Si quiere comenzar con algo pequeño, busque tareas marcadas con “bite-sized”.

Para editar código fuente, necesita tener código fuente. Esto significa que debe obtener una copia local del repositorio público de código fuente de Subversion. A pesar de lo simple que parezca esta tarea, puede ser algo complicada. Dado que el código fuente de Subversion se versiona con el propio Subversion, en realidad necesita “arrancar” obteniendo un cliente de Subversion funcional por otro método. Los métodos más habituales incluyen descargar la última distribución binaria (si es que hay una disponible para su plataforma), o descargar el último paquete de código fuente y compilar su propio cliente de Subversion. Si compila el código fuente, asegúrese de leer las instrucciones del fichero INSTALL en el directorio raíz del código fuente.

Una vez disponga de un cliente de Subversion funcional, puede obtener una copia local del código fuente de Subversion de http://svn.collab.net/repos/svn/trunk/: ^[51]

$ svn checkout http://svn.collab.net/repos/svn/trunk subversion
A  HACKING
A  INSTALL
A  README
A  autogen.sh
A  build.conf
…

El comando anterior obtendrá la ultima y más reciente versión del código de Subversion en un subdirectorio llamado subversion en su directorio actual. Obviamente, puede ajustar ese último parámetro como desee. Ignorando cómo llame al directorio de la copia local, una vez esta operación haya terminado, dispondrá del código fuente de Subversion. Por supuesto, todavía tendrá que obtener las librerías de apoyo (apr, apr-util, etc.)—vea el fichero INSTALL en el directorio raíz de su copia local para más detalles.

Ahora que tiene una copia local con la última versión del código fuente de Subversion, seguramente querrá leer el fichero HACKING en el directorio raíz de esa copia local. El fichero HACKING contiene instrucciones generales para contribuir con Subversion, incluyendo cómo formatear correctamente su código fuente para mantener la consistencia con el resto del código existente, cómo describir sus cambios propuestos con un mensaje de cambios efectivo, cómo verificar sus cambios, y demás. Los privilegios para hacer cambios en el repositorio del código fuente de Subversion se ganan—un gobierno basado en la meritocracia. ^[52] El fichero HACKING es un recurso de valor incalculable cuando llega la hora de asegurarse que sus cambios propuestos se ganan las alabanzas que merecen sin ser rechazados por detalles técnicos.

Habiendo entendido las reglas del código fuente y la comunidad, está preparado para realizar sus cambios. Lo mejor es intentar hacer cambios pequeños pero relacionados, incluso separando tareas grandes en fases, en lugar de hacer enormes modificaciones demoledoras. Los cambios que proponga serán más fáciles de entender (y por lo tanto, revisar) si distribuye el menor número de lineas de código posible para realizar la tarea correctamente. Tras realizar cada conjunto de cambios propuestos, su árbol Subversion debe estar en un estado en el cual el software compila sin ningún mensaje de aviso.

Subversion cuenta con una suite de tests de regresión bastante detallados ^[53], y se espera que los cambios que propone no harán que alguno de esos tests falle. Puede verificar sus cambios ejecutando make check (bajo Unix) desde el directorio raíz del código fuente. La forma más rápida para conseguir que sus contribuciones de código sean rechazadas (aparte de no proporcionar un buen mensaje de cambios) es proponer cambios que provocan fallos en la suite de tests.

En el mejor de los casos, usted habrá añadido nuevos tests a la suite de tests, los cuales verifican que sus cambios propuestos funcionan como espera. De hecho, a veces la mejor contribución que puede hacer una persona es añadir nuevos tests. Puede escribir tests de regresión para funcionalidades que actualmente funcionan en Subversion a modo de protección contra cambios futuros que puedan provocar un fallo en esas áreas. Además, puede escribir nuevos tests que demuestran fallos conocidos. Para este propósito, la suite de tests de Subversion le permite especificar que un test específico tiene como objetivo fallar (llamado XFAIL), así que mientras Subversion falle del modo que usted espera, el resultado del test XFAIL es considerado un éxito. En última instancia, cuanto mejor sea la suite de tests, menos tiempo se perderá diagnosticando potenciales fallos de regresión esquivos.

Tras realizar sus modificaciones al código fuente, componga un mensaje de cambios claro y conciso que los describa y la razón de éstos. Entonces, envíe un email a la lista de desarrolladores con su mensaje de cambios y la salida del comando svn diff (realizado desde el directorio raíz de su copia local de Subversion). Si los miembros de la comunidad consideran aceptables sus cambios, alguien con privilegios de escritura (permiso para crear nuevas revisiones en el repositorio de código fuente de Subversion) añadirá sus cambios al árbol público de código fuente. Recuerde que el permiso para realizar cambios directamente en el repositorio se obtiene por méritos—si demuestra comprensión de Subversion, competencia programando, y un “espíritu de equipo”, es probable que se le recompense con este permiso.