usuarios tortoise subversion subir proyecto crear svn version-control

svn - tortoise - ¿Cómo organizarías un repositorio de Subversion para proyectos de software internos?



svn repository (9)

Para mi empresa, uso svn + ssh y autenticación basada en claves. Puede hacerlo con clientes de Windows y clientes de Linux. Esto es realmente fácil de usar una vez que obtenga las llaves derechas mientras utiliza una clave ssh para iniciar sesión en lugar de escribir una contraseña.

Aquí hay un artículo sobre cómo configurar svn + ssh con notas sobre seguridad. Si entiendes todo esto y sigues estos pasos, comenzarás bien.

Este artículo describe una serie de formas de proteger aún más sus inicios de sesión ssh para las cuentas svn.

Recomiendo crear cuentas específicamente para el acceso svn sin otro acceso a ese servidor. Supongo que usaría una compilación diaria o una secuencia de comandos automatizada para actualizar sus procesos almacenados en la base de datos. Las compilaciones diarias pueden tener sus propias cuentas especiales y sus propias claves ssh. No me gusta que mis herramientas automatizadas se ejecuten con el mismo inicio de sesión que un usuario humano (para saber qué herramienta está rota).

Si no entiende todos los trucos de seguridad, la búsqueda en google puede ayudarlo. Si tiene problemas, configure uno sin los trucos de seguridad primero. Eso hace que sea un poco más fácil de solucionar.

¡Buena suerte y disfrute de los beneficios del control de código fuente!

Trabajo para una empresa cuya actividad principal no está relacionada con el software. La mayoría de la documentación para usar el control de fuente está escrita con un equipo de desarrollo que escribe para proyectos comerciales o de código abierto en mente. Como alguien que escribe en el software de la casa puedo decir que el trabajo se hace de manera diferente, entonces sería en un entorno comercial o de código abierto. Además, hay procedimientos almacenados y scripts de bases de datos que deben mantenerse sincronizados con el código.

En particular, estoy buscando sugerencias sobre cómo estructurar mejor el repositorio con el software interno en mente. La mayoría de la documentación sugiere tronco, ramas, etiquetas, etc. Y procedimientos para mantener los entornos de producción, prueba y desarrollo sincronizados con sus respectivas secciones en el repositorio, etc.

La configuración de repositorios SVN puede ser difícil solo en el sentido de cómo los organizas. Antes de configurar SVN, en realidad RTFM recibí el manual de Subversion en línea que trata sobre las técnicas organizativas para los repositorios y algunos de los errores que debes pensar de antemano, es decir, lo que no puedes hacer después de haber creado tus repositorios si decides cambiar de opinión. . Sugiero un pase a través de este manual antes de la instalación.

Para nosotros, como consultores, realizamos desarrollo de software personalizado y interno, así como también administración de documentos 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''. Generalmente ponemos lanzamientos en ''etiquetas'' usando ''release_w.xyz'' como la etiqueta para 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 de ''trabajo'', luego debajo de ese ''código'' y al lado de ''scripts'', etc. 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 ausencia de código, sugeriría un diseño de carpeta recto 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 repositorios, confirmar, actualizar, importar, etc.

Otra cosa es que la capacitación se debe considerar una 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!

Un repositorio para sus proyectos es probablemente suficiente. Me gusta el enfoque típico que indexa el diseño por proyecto (consulte esta sección del libro O''Reilly Subversion ):

/first-project/trunk /first-project/branches /first-project/tags /another-project/trunk /another-project/branches /another-project/tags /common-stuff/trunk /common-stuff/branches /common-stuff/tags

Tenga en cuenta que siempre puede reorganizar el repositorio más adelante.

Además, para las cosas internas, prefiero FSFS para el almacén de datos, a diferencia de Berkeley DB. FSFS es más resistente y la velocidad de las cajas no es una gran preocupación para pequeños equipos / proyectos. Puedes comparar y decidir por ti mismo.

Otras partes estándar de la receta incluyen Trac y un servidor Linux mínimo para alojar el repositorio en la LAN.

Después de publicar esta pregunta, hablé con un compañero de trabajo que me sugirió que leyera el artículo:

http://www.codinghorror.com/blog/archives/000968.html

En resumen, defiende que los programadores sean más conscientes de las ramificaciones. Me ayudó a ver que no hay una forma correcta de organizar nuestro repositorio. Para nuestro equipo, tendremos un tronco y dos ramas a largo plazo para pruebas y desarrollo. Además crearemos ramas separadas para cada tarea y fusionaremos los cambios de las ramas de tareas a medida que promovamos la tarea hasta las pruebas y la producción.

Creo en seguir el patrón básico con un directorio de proyecto con tronco, etiquetas, ramas debajo de él. Normalmente me gusta configurar el nivel superior como este

Los proyectos contienen todos los proyectos o módulos individuales. Versiones contiene etiquetas de lanzamiento que involucran varios módulos. Los usuarios tienen ramas de usuarios privadas. El administrador tiene mis scripts de gancho, scripts de respaldo, etc.

Las etiquetas de publicación son útiles si tiene un producto compuesto por varios módulos que pueden ser etiquetas diferentes para una versión específica (un anillo para enlazarlos y todo eso). Hace que sea más fácil para la custodia de la fuente y para los desarrollos hacer referencia a lo que compone la versión 1 o 2.

Para la subversión, también está Assembla, que viene con Trac y otras herramientas útiles. Es gratis o puede pagar una cuenta si necesita más espacio o usuarios por proyecto.

Como se especifica en este hilo , los VCS distribuidos (git, Mercurial) son un modelo mejor que los centralizados, debido a la facilidad de creación de sucursales, facilidad de fusión de sucursales, no es necesario configurar un servidor especial, no es necesario tener acceso a la red para trabajar y otros ventajas. Si trabaja solo, el DVCS le permite incorporar personas a sus proyectos si surge la necesidad con mucha facilidad.

De todos modos, respondiendo directamente a su pregunta, una forma de configurar SVN sería tener un repositorio por proyecto y, dependiendo de si los procedimientos almacenados y los scripts y bibliotecas están compartidos o no, cree un directorio en cada árbol de proyecto para los scripts y procedimientos almacenados. o un repositorio completo para el código compartido.