¿Un repositorio SVN o muchos?

Question

Si tiene proyectos múltiples, 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 actualmente puedo pensar es que se obtienen los números de revisión mixtos (¿y qué?), Y que no se puede usar svn:externals a menos que el repositorio sea realmente externo. (¿creo?)

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

Answer 1

El problema simple vs. múltiple se reduce a preferencias personales u organizacionales.

La gestión de múltiples vs. simples se reduce principalmente al control de acceso y mantenimiento.

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

Administro el mío. Hay un repositorio, múltiples proyectos, cada uno con sus propias etiquetas, troncales 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.

Hace poco 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 único repositorio, migre a múltiples si es necesario. La migración está casi completa y todavía están en un único repositorio, no se han presentado quejas o problemas debido a que se trata de un único repositorio.

Esto no es un problema binario, negro & blanco.

Haz lo que funcione para usted - si yo fuera en su posición, me combino proyectos en un único depósito lo más rápido que pude escribir los comandos, porque el costo sería una consideración importante en mi (muy , muy pequeña) compañía.

JFTR:

números de revisión de Subversion en realidad no tienen ningún significado fuera del repositorio. Si necesita nombres significativos para una revisión, crear una etiqueta

los mensajes de confirmación son fácilmente filtrados por ruta en el repositorio, por lo que la lectura sólo aquellos relacionados con un proyecto en particular es un ejercicio trivial.

---

Editar: Ver Blade 's respuesta para más detalles sobre el uso de una configuración única autorización/autenticación para SVN.

Answer 2

Mi sugerencia es una. A menos que tengas diferentes usuarios accediendo a cada uno, yo diría que utilizas múltiples.

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

Answer 3

Usaría varios repositorios. Además del problema de acceso del usuario, también hace que la copia de seguridad y la restauración sean más sencillas. Y si se encuentra en una posición en la que alguien quiere pagarle su código (y su historial), es más fácil darles solo un depósito de repositorio.

Sugeriría que la consolidación de repositorios solo por las políticas de carga de su proveedor de hosting no es una buena razón.

Answer 4

Personalmente, crearía nuevos repositorios para cada uno. Mantiene el proceso de verificación mucho más simple y hace que la administración en general sea más fácil, al menos con respecto 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.

Realmente sin embargo, sólo debe usar Git;)

Answer 5

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, será un gran desastre a corto plazo ...

Answer 6

Para su caso específico, un (1) repositorio es perfecto. Ahorrarás mucho dinero. Siempre aliento a las personas a usar un único repositorio. Debido a que es similar a un único sistema de archivos: Es más fácil

• Va a tener un único lugar en el que buscar el código
• Tendrá una única autorización
• Usted tendrá un solo número comprometerse (alguna vez ha tratado de construir un proyecto que se extiende sobre 3 repos?)
• puede volver a utilizar mejor las bibliotecas comunes y realizar un seguimiento de su progreso en estas librerías (SVN: los externos son PITA y no va a resolver todos los problemas)
• proyectos previstos como completamente diferente ems, pueden crecer juntos y compartir funciones e interfaces. Esto será muy difícil de lograr en repos múltiples.

Hay un único punto para múltiples repositorios: la administración de enormes repositorios es incómoda. Volcar/cargar grandes repostos toma mucho tiempo. Pero como no hace ninguna administración, creo que no será su preocupación;)

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

Por lo que tendrá menos problemas con un único repositorio. ¡Pero realmente debería pensar en el diseño del repositorio!

Answer 7

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

Nuestros proyectos son todos relacionados, diferentes módulos de enclavamiento que forman un conjunto de dependencias para cualquier aplicación determinada. Por esta razón, un único repositorio es ideal. Es posible que desee separar troncales/ramas/etiquetas para cada proyecto, pero aún así puede realizar un cambio atómico en toda su base de código en una única revisión. Esto es asombroso para refactorizar.

Answer 8

Si piensa utilizar una herramienta como trac que se integre con SVN, tiene más sentido utilizar un repositorio por proyecto.

Answer 9

Somos una pequeña compañía de software y utilizamos un solo repositorio para todo nuestro desarrollo. El árbol se parece a esto:

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

La idea era que tendríamos cliente y el trabajo interno de la misma cesión temporal, pero que llegó a tener a nuestra compañía como un "cliente" de sí mismo.

Esto ha funcionado muy bien para nosotros, y utilizamos 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 nos desfasa.

Answer 10

Tenga en cuenta que al tomar su decisión, many SVN repos can share the same config file.

Ejemplo (tomado de enlace de arriba):

Con cáscara:

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

del 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 

del 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 

Answer 11

similares a la sugerencia de la hoja de compartir archivos, aquí es una solución un poco más fácil, pero menos flexible. I nuestra configuración de este modo:

• /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 de crear un repositorio vacío. También mantengo el script de respaldo allí.

En "repository_files", guardo los directorios "conf" y "hooks" comunes a los que todos los repositorios tienen enlaces sym. Entonces, solo hay un conjunto de archivos. Sin embargo, esto elimina la posibilidad de tener acceso granular por proyecto sin romper los enlaces. Esa no era 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 esta forma, los archivos y scripts del repositorio también se encuentran bajo el control de la 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)" 

Answer 12

una cosa adicional a considerar es el hecho de que el uso de múltiples repositorios hacer que se pierda la capacidad de haber unificado de registro (comando svn log) esto solo será buena razón para elegir repositorio único.

Uso TortuiseSvn y encuentro 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 cruzada de proyectos (rutas, identificaciones de errores, mensajes, etc.) siempre es útil.

Answer 13

Similar a mlambie de usar un repositorio único, pero fue un poco más allá con la estructura de carpetas para ampliar fácilmente un tipo de proyecto en particular: proyectos basados ​​en html web vs. cs (C#) vs. sql (SQL crear/ejecutar scripts) vs. xyz (dominio de idiomas específicos como el AFL (AmiBroker Fórmula Language) o TS (TradeStation)):

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

nota, tienen el tronco vivo dentro de las ramas como lo trato como la rama por defecto. El único inconveniente a veces es cuando desea crear rápidamente otro proyecto que necesita para construir la estructura ProjectName/branches | tags. Utilizo la configuración de la aplicación simplemente como lugar para mantener los archivos de configuración de aplicaciones específicos en repos tanto para compartir fácilmente con otros (y sustituir Nombre del cliente por Nombre del proveedor y Nombre del proyecto por Nombre de la aplicación en esta estructura de carpetas, y las etiquetas sucursales pueden ser útiles para etiquetar configuraciones en diferentes sitios versiones de productos de proveedores también).

Bienvenido a cualquier comentario sobre mi estructura - Hace poco lo modifiqué y hasta ahora estoy contento, pero a veces me resulta complicado mantener las ramas | estructuras de etiquetas por proyecto - particularmente si el proyecto es simplemente una configuración de proyecto simplemente para Unit Test otro proyecto.