Perforce, proyectos compartidos entre múltiples soluciones

ACTUALIZAR :

Entonces resulta que podemos haber encontrado un error en Visual Studio 2003 (lo sé … no es sorpresa). Descubrimos que si las soluciones se agregaban al repository usando Visual Studio (usando Add Solution to Source Control) todo iba bien … vaya figura.


Así que estamos convirtiendo nuestro repository de VSS (si se puede llamar así) en Perforce y estamos teniendo problemas con proyectos incluidos en múltiples soluciones.

Nuestro repository podría verse así …

  • //Deposito
    • DevMain
      • Solución1
        • Project1 (comstack a una DLL)
      • Solution2 (tiene Project1 como reference de proyecto)
        • Proyecto2
      • Solution3 (tiene Project1 como reference de proyecto)
        • Proyecto3

Cuando se usa el Control de código fuente integrado en Visual Studio para Solution2, se queja de que los proyectos no están en la carpeta de soluciones actual y es posible que deseemos moverlo. Debido a que las soluciones múltiples hacen reference al Proyecto 1, nunca podemos organizarlo donde una solución no se queje …

¿Es la mejor práctica simplemente crear Project1 en DLL y almacenarlo en una carpeta Lib? ¿O hay un mejor path?

Gracias.

Tuvimos un problema similar y nos acercábamos mucho a él, como menciona @Toby Allen en su respuesta, a través de las especificaciones del cliente. Sin embargo, con el time esto se vuelve muy doloroso (configurar un nuevo miembro del equipo se vuelve cada vez más difícil a medida que las especificaciones del cliente se vuelven cada vez más intrincadas, la automation es mucho más complicada porque las cosas están "en flujo" :-)).

Eventualmente, desarrollamos nuestra estrategia para usar una estructura de directory y una bifurcación en su lugar. La estructura del directory es la siguiente:

//depot /products /(product_name) /doc /lib /(3rd_party_libname) (DLLs) /(another_3rd_party_libname) (DLLs) /src /Project1 (files, csproj, vbproj, etc) /Project2 (files, csproj, vbproj, etc) /Project3 (files, csproj, vbproj, etc) Solution1.sln (includes src/Project1) Solution2.sln (includes src/Project1, src/Project2) Solution3.sln (includes src/Project1, src/Project3) /(another_product_name) /doc /lib /src (solutions) /shanetworking /(shanetworking_lib_name) /doc /lib /src (solutions) /(another_shanetworking_lib_name) /doc /lib /src (solutions) 

Tenga en count que la misma estructura se repite en toda la estructura (doc / lib / src / solutions). Lib contiene bibliotecas "externas": bibliotecas de terceros que se incluyen en las references de proyectos. Src contiene una list plana de todos los proyectos que son parte de un producto en particular. Las soluciones se usan para "combinar" proyectos de muchas maneras. Pienso en el directory de src como un contenedor con "lo que está disponible", las soluciones se seleccionan de este contenedor y se combinan los proyectos (según sea necesario).

Las bibliotecas que se comparten entre varios productos van al directory compartido. Una vez en el directory compartido, se tratan como productos independientes: tienen su propio ciclo de publicación y nunca se unen a los productos como fuente. Las bibliotecas compartidas se incorporan a los productos mediante la bifurcación del set / ensamblados de liberación de la biblioteca compartida en el directory lib del producto -> desde la perspectiva del producto, no hay diferencia entre una biblioteca de terceros y una biblioteca compartida. Esto nos permite controlar qué producto está usando qué versión de una biblioteca compartida (cuando un producto quiere nuevas características, debe ramificarse explícitamente en una versión más nueva de una biblioteca compartida, al igual que includeía una nueva versión de una biblioteca de terceros, con todos los pros y contras que lo acompañan).

En resumen, nuestra estructura tiene el concepto de dos "types" de bibliotecas compartidas:

  • proyectos locales para un producto, utilizados por múltiples soluciones (incluidos en una list plana de proyectos en el directory src, múltiples soluciones pueden hacer reference a ellos)
  • proyectos utilizados por varios productos (agregados al directory compartido, tratados como bibliotecas de terceros con versiones independientes de los productos)

La solución debería ser volver a enlazar Solution1 con el server de control de origen cada vez que se agregue a un nuevo proyecto. (Está en File-> Source Control-> Change Source Control).

Esto solo debería hacerse una vez por escritorio por solución.

No sé mucho sobre el uso de Visual Studio con Perforce, pero podría considerar la creación de vistas de espacios de trabajo que vinculen Project1 a Solution2, Solution3, etc., donde sea necesario.

Si entiendo correctamente, quiere saber cómo se almacenan los files en el disco para que difieran de cómo se almacenan en Perforce. Si este es el caso, y usted simplemente no puede networkingefinir la reference dentro de VS, entonces un cliente hábilmente diseñado puede hacer el truco.

 Client: Client_Solution2 Description: Created by Me. Root: C:/Development/Solutions View: //depot/Devmain/Solution1/... //Client_Solution2/Solution2/Solution1/... //depot/Devmain/Solution2/... //Client_Solution2/Solution2/... 

Esto le dará una estructura donde Solution1 es un subdirectory de la solución 2.