visual-studio - instalar - visual studio code wrap tag
¿La mejor práctica para crear repositorios de subversión? (8)
Nuestro equipo (5-10 desarrolladores) planea adoptar Subversion para nuestros proyectos / soluciones .NET (Visual Studio) (Servidor VisualSVN, TortoiseSVN / VisualSVN).
¿Cuál es la mejor manera de organizar un nuevo árbol de repositorio ? ¿Está bien usar un gran repositorio o es mejor crear repositorios diferentes para cada línea de solución / producto, etc.?
Nuestros proyectos se pueden clasificar de esta manera (ejemplo):
- Línea principal de productos
- Aplicación web principal
- Biblioteca 1
- Biblioteca 2
- ...
- Cliente de Windows
- Otro cliente de Windows
- Servicio de Windows
- Aplicación web principal
- Herramientas
- Herramienta A
- Herramienta B
- Línea de producto 2
- Software 1
- Software 2
- Línea de productos 3
- Aplicación 1
- Aplicación 2
Estoy usando un repositorio y muchos proyectos de la siguiente manera:
Projects
Project Name
trunk
branches
tags
Mi única preocupación es la copia de seguridad y restauración. La copia de seguridad SVN se realiza en el nivel del repositorio, por lo que la restauración restaurará todos los proyectos en lugar de solo uno.
Jirong
Generalmente, desea utilizar un repositorio separado en cualquier caso en el que espere permisos de acceso diferentes (es decir, algunos desarrolladores deben tener acceso de confirmación a un proyecto, pero no a otro, o un proyecto tiene una interfaz pública de solo lectura pero otro no lo hace). t).
Desea tener todo en un repositorio si no necesita ese nivel de control de acceso, especialmente si necesita poder copiar o mover archivos entre proyectos (es decir, los proyectos pueden compartir código).
Coloque su división troncal / etiquetas / ramificación en cualquier nivel que corresponda a un fragmento de código que pueda liberar como un único paquete (es decir, piense dónde marcaría). Esto no es crítico para hacerlo bien al principio, ya que estos no son diferentes internamente de cualquier otra carpeta, por lo que puedes mover las cosas más tarde, aunque por supuesto es mejor no tener ese problema.
Tenemos repositorios separados para cada proyecto; pero la razón principal es por razones de acceso, además, si el cliente quiere una copia de su fuente, podemos entregárselo sin demasiado alboroto. Si miras los archivos de configuración en conf, no es tan difícil tener un archivo de configuración universal que funcione para todos tus proyectos. Lo hacemos así:
[general]
anon-access = none
auth-access = write
password-db = ../../conf/passwd
authz-db = ../../conf/authz
authz:
[groups]
AOS = nathan,mark
[AOS:/]
@AOS = rw
frew = rw
y luego, por supuesto, passwd:
[users]
frew = password
nathan = awesome
mark = station
Tenemos un solo repositorio estructurado de esa manera. Todo lo que es trabajado por más de unas pocas personas y / o en desarrollo activo se configura con trunk / tags / branch / en la carpeta principal.
Probablemente pondríamos el conjunto de carpetas branch-tags-trunk debajo de cada subcarpeta que haya enumerado, excepto tal vez una biblioteca o dos que no están en desarrollo activo.
Trate de mantener el material al que se accede con regularidad (código, scripts) por separado del material ''write-once and commit to backup'' . Tener que pagar / actualizar miles de jpegs solo para cambiar unas pocas líneas de código se vuelve aburrido muy rápidamente.
Usamos un gran repositorio, y simplemente tenemos todo estructurado en subcarpetas (/ project1, / project2, etc.) y eso parece funcionar bien.
¡El proyecto Apache tiene un enorme repositorio svn y parece funcionar bien para ellos! :)
En términos de organización, la estructura que proporcionó parece bastante razonable. Creo que todo vale, más o menos, siempre que sea racional (es decir, mezclar cada herramienta con cada proyecto es probablemente una mala idea, etc.). Así que elija algo que funcione para usted (herramientas /, proyectos / etc.). Subversion también tiene un buen soporte para mover cosas en el repositorio, por lo que siempre puede cambiar si es necesario.
- Punto de vista de gestión de SVN Prefiero 1 repositorio.
- Punto de vista del programador Prefiero 1 repositorio.
- Server Administrator Prefiero 1 repostitory.
- Desde el punto de vista de la seguridad, es preferible no poner todos sus huevos en una sola canasta.
Su estructura de repositorio será única para su empresa y sus productos. Mantenemos los nuestros en un repositorio. Nuestra estructura algo así como esto.
- /
- Proyectos
- Nombre del proyecto
- el maletero
- ramas
- etiquetas
- Nombre del proyecto
- Documentación
- Proyecto 1
- Bibliotecas compartidas
- Súper clase de cuerda
- Pequeñas utilidades
- Mejora de vim X
- Proyectos