Hay maneras estándar recomendadas para organizar un repositorio. La mayoría de las personas crean un directorio trunk que contendrá la “línea principal” de desarrollo, un directorio branches que contendrá copias de las ramas, y un directorio tags que contendrá copias de las etiquetas. Si un repositorio sólo almacena un proyecto, entonces la gente a menudo crea estos directorios en el directorio raíz:

/trunk
/branches
/tags

Si un repositorio contiene múltiples proyectos, los administradores normalmente indexan la estructura por proyecto (vea “Escogiendo el esquema de repositorio” para leer más sobre “raíces de proyecto”):

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

Por supuesto, es libre de ignorar estas estructuras comunes. Puede crear cualquier tipo de variación, lo que sea mejor para usted y su equipo. Recuerde que sea lo que sea lo que elija, no es una decisión final. Puede reorganizar su repositorio en cualquier momento. Dado que las ramas y etiquetas son directorios ordinarios, el comando svn move puede moverlos o renombrarlos como desee. Cambiar de una estructura a otra es una cuestión de ejecutar una serie de movimientos en el servidor; si no le gusta cómo se organizan las cosas en el repositorio, simplemente juegue un poco con los directorios.

Recuerde, no obstante, que aunque mover directorios puede ser fácil, necesita ser considerado con sus usuarios. Sus movimientos pueden desorientar a los usuarios que tengan copias locales de trabajo. Si un usuario tiene una copia local de un directorio particular del repositorio, su operación svn move quizás elimine la ruta de la última revisión. Cuando el usuario ejecute svn update, se le informará que su copia local usa una ruta que ya no existe, y el usuario se verá forzado a hacer svn switch a otra ubicación.

Otra buena característica del modelo de Subversion es que las ramas y las etiquetas pueden tener vidas infinitas, igual que cualquier otro elemento versionado. Por ejemplo, suponga que finalmente termina todo su trabajo en una rama personal del proyecto calc. Tras fusionar todos sus cambios de vuelta en /calc/trunk, ya no hace falta que el directorio de su rama privada permanezca visible:

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Committed revision 375.

Y desapareció su rama. Por supuesto no ha desaparecido realmente: el directorio simplemente falta en la revisión HEAD, y ya no distrae a nadie más. Si usa svn checkout, svn switch, o svn list para examinar una revisión anterior, seguirá pudiendo ver su antigua rama.

Si navegar por su directorio borrado no es suficiente, siempre puede devolverle la vida. Resucitar datos es muy fácil en Subversion. Si hay un directorio (o fichero) borrado que querría volver a poner en HEAD, simplemente cópielo con svn copy -r de la revisión antigua:

$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                  http://svn.example.com/repos/calc/branches/my-calc-branch

Committed revision 376.

En nuestro ejemplo, su rama personal tuvo un periodo de actividad relativamente corto: puede haberla creado para corregir un fallo o implementar una nueva característica. Cuando su tarea está terminada, así lo está su rama. No obstante, en el desarrollo de software también es común tener dos ramas “principales” que viven en paralelo por largos periodos de tiempo. Por ejemplo, suponga que es el momento de hacer público el proyecto estable calc, y sabe que va a necesitar un par de meses corregir posibles fallos del mismo. No quiere que la gente añada nuevas características al proyecto, pero tampoco quiere decirle a los desarrolladores que dejen de programar. Así que crea una rama “estable” del software que no cambiará mucho:

$ svn copy http://svn.example.com/repos/calc/trunk \
         http://svn.example.com/repos/calc/branches/stable-1.0 \
         -m "Creating stable branch of calc project."

Committed revision 377.

Y ahora los desarrolladores son libres de continuar añadiendo características novísimas (o experimentales) a /calc/trunk, y usted puede declarar como política del proyecto que sólo las correcciones de fallos serán realizadas en /calc/branches/stable-1.0. Es decir, a medida que la gente continúa su trabajo en el tronco, un humano portará selectivamente las correcciones de fallos a la rama estable. Incluso después de haber lanzado la rama estable, probablemente continuará manteniéndola por un largo tiempo—es decir, tanto como desee continuar el soporte de esa versión para sus usuarios.