Organización de soluciones, proyectos y SVN

Question

Me gustaría obtener ayuda para configurar un proyecto en SVN con respecto a la estructura de directorios. He leído varias respuestas al respecto en SO, pero como soy nuevo en esto, la mayoría de ellos son difíciles de entender.

Estoy construyendo una sola biblioteca, en la que varios otros proyectos distinta depende de:

Necesito la capacidad de exportar MyLibrary (cabeceras y .LIB solamente) fácilmente para su uso por parte de terceros

MyLibrary1

• Depende de bibliotecas externas, debe ser capaz de manejar diferentes versiones de estas bibliotecas!

MyLibrary2

• Depende de bibliotecas externas HOQF, Glew, ...

Proyecto 1, 2, 4, 5, 6 ...

• Depends en MyLibrary1, 2, o ambos
• Cada proyecto podría necesitar versiones para múltiples plataformas (OSX, ventanas ...)

Me gustaría saber de una buena manera de organizar esto, tenga en cuenta que soy bastante nuevo en esto, una respuesta más pedante sería útil. Por ejemplo, si escribe algo como/src, explique lo que se supone que debe incluir. Yo sería capaz de adivinar, pero no voy a estar seguro =)

//////////////////////////////// ////////////////////////////////////////////////// //////////////////////////

// Editar

me puedo poner esto en un comentario, así que aquí va: @JN, gracias por la extensa respuesta, me gustaría aclarar algunas cosas, espero que entendí lo que quería decir correctamente:

root 
    library foo 
     /branches   // old versions of foo 
     /tags    // releases of foo 
     /trunk    // current version 
      /build   // stuff required by makefiles 
      /tools   // scripts to launch tests ect 
      /data   // test data needed when running 
      /output   // binaries, .exe files 
      /dependencies // libraries that foo needs 
       /lib name 
        include 
        lib 
      /docs   // documentation 
      /releases  // generated archives 
      /sample   // sample project that shows how to use foo 
      /source   // *.h, *.cpp 

    program bar 
     /branches   // old versions of bar 
     /tags    // releases of bar 
     /trunk    // current version 
      /build   // stuff required by makefiles 
      /tools   // scripts to launch tests ect 
      /data   // test data needed when running 
      /output   // binaries, .exe files 
      /dependencies // libraries that bar needs 
       /lib name 
        include 
        lib 
      /docs   // documentation 
      /releases  // generated archives 
      /sample   // sample project that shows how to use bar 
      /source   // *.h, *.cpp 

1) ¿a dónde van los archivos * .sln? ¿En construccion?

2) necesito para copiar foo/fuente en la barra/dependencias/foo/include? Después de todo, depende de la barra de Foo

3) ¿A dónde van los archivos * .dll? Si foo tiene dependencias en archivos dll, entonces todos los programas que usen foo necesitan acceso a los mismos archivos dll. ¿Debería entrar esto en root/dlls?

Answer 1

Existen varios niveles para sus preguntas: cómo organizar un árbol fuente de proyecto único, cómo mantener los diferentes proyectos juntos, cómo mantener las dependencias de esos proyectos, cómo mantener diferentes variantes de cada proyecto y cómo empaquetar ellos.

Por favor, tenga en cuenta que cualquier cosa que hagas, tu proyecto muy probable que crezca lo suficientemente grande como para que sea inadaptado. Es normal cambiar la estructura varias veces en la vida de un proyecto. Tendrá la sensación de que ya no está bien cuando eso suceda: generalmente es cuando la configuración le molesta más de lo que ayuda.

---

1 - El mantenimiento de las diferentes variantes de cada proyecto

No tienen variantes para cada proyecto, que no va a resolver diversas variantes mediante el mantenimiento de versiones parralel o ramas. Tenga un árbol de fuentes único para cada proyecto/biblioteca que se pueda usar para todas las variantes. No administre diferentes "sistemas operativos", administre diferentes funciones. Es decir, tiene variantes en cosas como "sockets posix de soporte" o "UI de soporte". Eso significa que si aparece un nuevo sistema operativo, entonces solo necesita elegir el conjunto de características que admite en lugar de comenzar una nueva versión.

Cuando se necesita un código específico, cree una interfaz (clase abstracta en C++) e implemente el comportamiento con respecto a ella. Eso aislará el código problemático y ayudará a agregar nuevas variantes en el futuro. Use una macro para elegir la correcta en el momento de la compilación.

---

2 - El mantenimiento de las dependencias de cada proyecto

tiene una carpeta específica "dependencias" en el que cada subcarpeta contiene todo lo necesario para una dependencia (es decir incluye dependencias y sub). Al principio, cuando la base de código no es demasiado grande, no le importa demasiado asegurar automáticamente que todas las dependencias sean compatibles entre sí, guárdelas para más adelante.

No intente fusionar las dependencias desde su ubicación raíz más arriba en la jerarquía svn. Entregar formalmente cada nueva versión a los equipos que la necesiten, hasta ellos actualizar su propia parte del SVN con ella.

No intente utilizar varias versiones de la misma dependencia a la vez. Eso terminará mal. Si realmente necesita (pero trate de evitarlo tanto como pueda), bifurque su proyecto para cada versión.

---

3 - Mantener los diferentes proyectos

te aconsejo para mantener los proyectos de cada repositorio de forma independiente (con SVN, aún podría ser el mismo repo, pero en carpetas separadas). Las ramas y etiquetas deben ser específicas para un proyecto, no todas. Intenta limitar al máximo el número de ramas, no resuelven problemas (incluso con git). Utilice las ramas cuando tenga que mantener diferentes versiones cronológicas en paralelo (, no las variantes) y luchar tanto como pueda antes de que realmente lo haga, todos se beneficiarán con el uso del código más nuevo.

Eso permitirá imponer restricciones de seguridad (no estoy seguro si es factible con el SVN de vanilla, pero hay algunos servidores de libre disponibilidad que lo soportan).

Recomiendo enviar notificaciones por correo electrónico cada vez que alguien se comprometa en un proyecto con cualquier persona potencialmente interesada.

---

4 - Proyecto de organización árbol de fuentes

Cada proyecto debe tener las siguientes estructuras SVN:

• tronco (versión actual)
• ramas (las versiones más antiguas, todavía en uso)
• etiquetas (versiones, usadas para crear ramas sin pensar demasiado cuando se requieren parches) Cuando el proyecto se vuelve más grande r, organizar ramas y etiquetas en subcarpetas (por ejemplo, branches/V1.0/V1.1 y branches/V2.0/V2.1).

tiene una carpeta raíz con las siguientes subcarpetas: (algo de esto puede ser creado por VC en sí)

• sistema de construcción (material requerido por los archivos MAKE u otros)
• Herramientas (si lo hay , como una herramienta de XSLT o compilador SOAP, guiones para poner en marcha las pruebas)
• de datos (datos de prueba que necesita mientras correr)
• de salida (donde el sistema de construcción poner los binarios)
• salida de temperatura (archivos temporales creados por la compilación, opcional)
• Dependencias
• Docs (si las hubiere;) o documentos generados)
• de prensa (los archivos generados ver más adelante)
• muestra (un pequeño proyecto que demostrar cómo utilizar el proyecto/biblioteca)
• Fuente (no me gusta dividir los encabezados y .cpp, pero esa es mi manera)
  • evitar demasiados niveles de subcarpetas, es difícil buscar los árboles, las listas son más fácil
  • definir adecuadamente el orden de construcción de cada carpeta (menos necesario para VC pero aún así)
  • hago mis espacios de nombres coinciden con los nombres de mis carpetas (viejos hábitos de Java, pero funciona)
  • definir claramente la parte "pública" que es necesario exportación
  • Si el proyecto es lo suficientemente grande como para contener varios binarios/dlls cada uno debe tener su propia carpeta

no cometer ningún binario que generan, sólo las versiones. A los binarios les gusta entrar en conflicto entre ellos y causar dolor a las otras personas en el equipo.

---

5 - Embalaje los proyectos

primer lugar, asegúrese de incluir un archivo de texto con la revisión SVN y la fecha, no hay una forma automatizada de hacer eso con los apoyos de automóviles.

Debe tener un script para generar releases (si el tiempo lo permite). Verificará que todo esté comprometido, generará un nuevo número de versión ... Crear un archivo zip/tar.El archivo gz debe confirmar/archivar, cuyo nombre contiene la revisión SVN, la rama y la fecha actual (el formato debe ser normalizado en todos los proyectos). El archivo debe tener todo lo necesario para ejecutar la aplicación/usar la biblioteca en una estructura de archivos. Crea una etiqueta para que puedas partir de ella y solucionar los errores de emergencia.