La configuración de repositorios SVN puede ser complicada solo en el sentido de cómo los organiza. Antes de configurar SVN, en realidad RTFM conocía el Subversion manual en línea que analiza las técnicas organizativas para repositorios y algunos de los errores que debería pensar de antemano, es decir, lo que no puede hacer después de haber creado sus repositorios si decide cambiar de opinión. Sugiero un pase a través de este manual antes de la instalación.
Para nosotros, como consultores, hacemos desarrollo de software personalizado y interno, así como algunos documentos de gestión a través de SVN. Nos interesaba crear un repositorio para cada cliente y uno para nosotros. Dentro de cada repositorio, creamos carpetas para cada proyecto (software u otro). Esto nos permitió segmentar el acceso de seguridad por repositorio y por cliente e incluso por proyecto dentro de un repositorio. Yendo más profundo, para cada proyecto de software creamos carpetas de 'trabajo', 'etiquetas' y 'ramas'. En general, publicamos lanzamientos en 'etiquetas' usando 'release_w.x.y.z' como la etiqueta de un estándar.
En su caso, para mantener sprocs, scripts y otros documentos relacionados sincronizados, puede crear una carpeta de proyecto, luego debajo una carpeta 'working', luego debajo de ese 'código' y al lado de 'scripts' , etc. Luego, cuando etiqueta la versión de trabajo para su lanzamiento, termina etiquetándolo todo junto.
\Repository
\ProjectX
\Working
\Code
\Scripts
\Notes
\Tags
\Branches
En cuanto a la no-código, sugeriría una distribución de la carpeta directamente por proyecto o tipo de documento (manuales, políticas, etc.). En general, con los documentos y dependiendo de cómo funciona su empresa, basta con tener el historial de versiones/registros.
Ejecutamos SVN en Windows junto con WebSVN que es un gran visor de repositorio de código abierto. Lo usamos para dar a los clientes acceso web a su código y todo está impulsado por la seguridad subyacente de Subversion. Internamente, usamos TortoiseSVN para administrar los repositorios, confirmar, actualizar, importar, etc.
Otra cosa es que la capacitación se debe considerar como parte integral de su implementación. Los usuarios nuevos en el control de versiones pueden tener dificultades para entender lo que está sucediendo. Descubrimos que darles instrucciones funcionales (hacer esto al crear un proyecto, hacer esto al actualizar, etc.) fue muy útil mientras aprendían los conceptos. Creamos un repositorio de "recinto de seguridad" donde los usuarios pueden jugar todo lo que quieran con documentos y carpetas para practicar, también puede resultar útil para experimentar qué políticas establecer.
¡Buena suerte!
Tenga en cuenta que el estándar establecido para las carpetas de nivel superior es 'trunk, branches, tags'. Si usa 'working' en lugar de' trunk', confundirá muchas herramientas que funcionan con repositorios SVN. Desafío fuertemente a hacer eso. – sleske