¿Un repositorio SVN o muchos?

Si tiene varios proyectos no relacionados, ¿es una buena idea ponerlos en el mismo repositorio?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

¿O crearías nuevos repositorios para cada uno?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

¿Cuáles son los pros y los contras de cada uno? Todo lo que puedo pensar actualmente es que obtienes números de revisión mixtos (¿y qué?) Y que no puedes usar a svn:externalsmenos que el repositorio sea realmente externo. (¿Yo creo que?)

La razón por la que pregunto es porque estoy considerando consolidar mis múltiples repositorios en uno, ya que mi host SVN ha comenzado a cobrar por repositorio.

El problema de los únicos frente a los múltiples se reduce a las preferencias personales u organizativas.

La gestión de múltiples frente a individuales se reduce principalmente al control de acceso y al mantenimiento.

El control de acceso para un solo repositorio puede estar contenido en un solo archivo; Varios repositorios pueden requerir varios archivos. El mantenimiento tiene problemas similares: una copia de seguridad grande o muchas copias de seguridad pequeñas.

Yo administro el mío. Hay un repositorio, varios proyectos, cada uno con sus propias etiquetas, tronco y ramas. Si uno se vuelve demasiado grande o necesito aislar físicamente el código de un cliente para su comodidad, puedo crear rápida y fácilmente un nuevo repositorio.

Recientemente consulté con una empresa relativamente grande sobre la migración de múltiples sistemas de control de código fuente a Subversion. Tienen ~ 50 proyectos, que van desde aplicaciones muy pequeñas hasta aplicaciones empresariales y su sitio web corporativo. ¿Su plan? Comience con un solo repositorio, migre a varios si es necesario. La migración está casi completa y todavía están en un solo repositorio, no se informan quejas ni problemas debido a que es un solo repositorio.

Este no es un problema binario, en blanco y negro.

Haga lo que funcione para usted : si estuviera en su posición, combinaría proyectos en un solo repositorio tan rápido como pudiera escribir los comandos, porque el costo sería una consideración importante en mi (muy, muy pequeña) empresa.

JFTR:

Los números de revisión en Subversion realmente no tienen significado fuera del repositorio. Si necesita nombres significativos para una revisión, cree una ETIQUETA

Los mensajes de confirmación se filtran fácilmente por ruta en el repositorio, por lo que leer solo los relacionados con un proyecto en particular es un ejercicio trivial.

Editar: consulte la respuesta de Blade para obtener detalles sobre el uso de una única configuración de autorización / autenticación para SVN.

Para su caso específico, un (1) repositorio es perfecto. Ahorrarás mucho dinero. Siempre animo a la gente a usar un único repositorio. Porque es similar a un solo sistema de archivos: es más fácil

• Tendrás un solo lugar donde buscarás código
• Tendrás una única autorización
• Tendrá un solo número de confirmación (¿alguna vez intentó construir un proyecto que se distribuye en 3 repositorios?)
• Puede reutilizar mejor las bibliotecas comunes y realizar un seguimiento de su progreso en estas bibliotecas (svn: los externos son PITA y no resolverán todos los problemas)
• Los proyectos planificados como elementos completamente diferentes pueden crecer juntos y compartir funciones e interfaces. Esto será muy difícil de lograr en múltiples repositorios.

Hay un solo punto para varios repositorios: la administración de repositorios enormes es incómoda. La descarga / carga de repositorios enormes lleva mucho tiempo. Pero como no haces ninguna administración, creo que no será de tu incumbencia;)

SVN escala muy bien con repositorios más grandes, no hay desaceleración incluso en repositorios enormes (> 100 GB).

Así tendrá menos problemas con un solo repositorio. ¡Pero realmente deberías pensar en el diseño del repositorio!

Usaría múltiples repositorios. Además del problema de acceso de los usuarios, también facilita la copia de seguridad y la restauración. Y si se encuentra en una posición en la que alguien quiere pagarle por su código (y su historial), es más fácil darles un volcado de repositorio.

Sugeriría que consolidar repositorios solo por las políticas de cobro de su proveedor de alojamiento no es una muy buena razón.

Usamos un solo repositorio. Mi única preocupación era la escala, pero después de ver el repositorio de ASF (700k revisiones y contando) estaba bastante convencido de que el rendimiento no sería un problema.

Nuestros proyectos están todos relacionados, diferentes módulos entrelazados que forman un conjunto de dependencias para cualquier aplicación dada. Por esta razón, un único repositorio es ideal. Es posible que desee troncos / ramas / etiquetas separados para cada proyecto, pero aún puede realizar un cambio de forma atómica en todo su código base dentro de una sola revisión. Esto es genial para refactorizar.

Tenga en cuenta que al tomar su decisión, muchos repositorios SVN pueden compartir el mismo archivo de configuración.

Ejemplo (tomado del enlace anterior):

Con cáscara:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

Archivo: /var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

Archivo: / var / svn / conf / authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

Me gustaría crear repositorios separados ... ¿Por qué? Los números de revisión y los mensajes de confirmación simplemente no tendrán ningún sentido si tiene muchos proyectos no relacionados en un solo repositorio, seguramente será un gran lío a corto plazo ...

Somos una pequeña empresa de software y utilizamos un único repositorio para todo nuestro desarrollo. El árbol se ve así:

/client/<clientname>/<project>/<trunk, branches, tags>

La idea era que tuviéramos trabajo interno y de cliente en el mismo repositorio, pero acabamos teniendo a nuestra empresa como un "cliente" de sí misma.

Esto nos ha funcionado muy bien y usamos Trac para interactuar con él. Los números de revisión se encuentran en todo el repositorio y no son específicos de un proyecto, pero eso no es una fase.

Personalmente, crearía nuevos repositorios para cada uno. Mantiene el proceso de pago mucho más simple y facilita la administración en general, al menos en lo que respecta al acceso de los usuarios y las copias de seguridad. Además, evita el problema del número de versión global, por lo que el número de versión es significativo en todos los proyectos.

Sin embargo, realmente deberías usar git;)

Una cosa adicional a considerar es el hecho de que el uso de múltiples repositorios hace que pierda la capacidad de tener un registro unificado (comando svn log), esto por sí solo será una buena razón para elegir un solo repositorio.

Utilizo TortuiseSvn y descubrí que la opción "Mostrar registro" es una herramienta obligatoria. aunque sus proyectos no están relacionados, estoy seguro de que encontrará que tener una información global centralizada entre proyectos (rutas, identificadores de errores, mensajes, etc.) siempre es útil.

Si planea usar una herramienta como trac que se integra con SVN, tiene más sentido usar un repositorio por proyecto.

Similar a la sugerencia de Blade sobre compartir archivos, aquí hay una solución un poco más fácil, pero menos flexible. Configuré el nuestro así:

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

En "bin", guardo un script llamado svn-create.sh que hará todo el trabajo de configuración para crear un repositorio vacío. También guardo el script de respaldo allí.

En "repository_files", mantengo directorios comunes "conf" y "hooks" a los que todos los repositorios tienen enlaces simbólicos. Entonces, solo hay un conjunto de archivos. Sin embargo, esto elimina la capacidad de tener acceso granular por proyecto sin romper los enlaces. Eso no fue una preocupación donde configuré esto.

Por último, mantengo el directorio principal / var / svn bajo control de código fuente ignorando todo en svnroot. De esa forma, los archivos del repositorio y los scripts también están bajo control de código fuente.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Similar al uso de un solo repositorio de mlambie, pero fue un poco más allá con la estructura de carpetas para hacer zoom fácilmente a un tipo particular de proyectos: proyectos basados ​​en web html versus cs (C #) versus sql (SQL crear / ejecutar scripts) versus xyz ( Idiomas específicos de dominio como afl (lenguaje de fórmulas AmiBroker) o ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Tenga en cuenta que tengo un tronco en vivo dentro de las ramas, ya que lo trato como la rama predeterminada. El único problema a veces es cuando desea crear rápidamente otro proyecto, necesita construir la estructura de etiquetas ProjectName / branch | tags. Utilizo la configuración de la aplicación simplemente como un lugar para mantener archivos de configuración de aplicaciones específicos en repositorio para que otros puedan compartir fácilmente (y sustituyo ClientName por VendorName y ProjectName por AppName en esta estructura de carpetas; y las ramas | etiquetas pueden ser útiles para etiquetar configuraciones en diferentes versiones de productos de proveedores también).

Bienvenido a cualquier comentario sobre mi estructura: recientemente lo cambié a esto y hasta ahora estoy bastante contento, pero a veces me resulta oneroso mantener las estructuras de ramas | etiquetas por proyecto, especialmente si el proyecto es simplemente una configuración de proyecto simplemente para probar unitario en otro proyecto.

Mi sugerencia es una. A menos que tenga diferentes usuarios accediendo a cada uno, entonces yo diría que use varios.

Pero nuevamente, incluso esa no es una buena razón para usar múltiples.