tortoise tag subversion repositorio create crear svn

tag - ¿Un repositorio SVN o muchos?



tortoise svn (13)

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 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 comenzó a cobrar por repositorio.

El problema individual versus múltiple se reduce a preferencias personales u organizacionales.

La administración de múltiples versus 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.

Yo 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.

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 ú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.

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 único 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 un TAG

Los mensajes de compromiso se filtran fácilmente por la ruta en el repositorio, por lo que leer solo aquellos relacionados con un proyecto en particular es un ejercicio trivial.

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

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

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

Para su caso específico, un (1) repositorio es perfecto. Ahorrarás mucho dinero. Siempre aliento a las personas 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 sola autorización
  • Tendrá un único número de compromiso (¿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 librerías (svn: externals son PITA y no resolverán todos los problemas)
  • Los proyectos planeados como elementos completamente diferentes, pueden crecer juntos y compartir funciones e interfaces. Esto será muy difícil de lograr en repos múltiples.

Existe un único punto para múltiples repositorios: la administración de grandes repositorios es incómoda. Dumping / carga enormes repos toma mucho tiempo. Pero como no haces ninguna administración, creo que no será tu problema;)

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

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

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, solo deberías usar git;)

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

En "repository_files", tengo 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 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)"

Similar a mlambie de usar un repositorio único, pero fue un poco más allá con la estructura de carpetas para hacer zoom fácilmente a un tipo de proyecto en particular: proyectos basados ​​en html web vs. cs (C #) vs. sql (SQL crear / ejecutar scripts) vs. xyz ( Idiomas específicos del dominio como afl (AmiBroker Formula Language) o ts (TradeStation)):

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

Tenga en cuenta que tengo el tronco en vivo dentro de las ramas, ya que lo trato como la rama predeterminada. 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).

Bienvenidos a cualquier comentario sobre mi estructura. Hace poco cambié a esto y hasta ahora estoy contento, pero a veces me resulta complicado mantener las estructuras de las ramas por proyecto, particularmente si el proyecto es simplemente una configuración de proyecto simplemente para probar otro proyecto.

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

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

La idea era que tendríamos el cliente y el trabajo interno en el mismo repositorio, pero terminamos teniendo a nuestra compañía como un "cliente" de sí mismo.

Esto nos ha funcionado muy bien 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.

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

Ejemplo (tomado del enlace de arriba):

En shell:

$ 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

Una cosa más a tener en cuenta 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 solo será una buena razón para elegir un único repositorio.

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

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 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.

Yo usaría múltiples 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 cobro de su proveedor de hosting no es una buena razón.

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