visual-studio version-control perforce

¿Cómo funciona la integración de control de fuente de Visual Studio con Perforce?



visual-studio version-control (9)

Introducción

No estoy de acuerdo con la afirmación de que la integración de Perforce en Visual Studio es "terrible". Más bien, lo definiría como "la experiencia fuera de la caja es menos que óptima" :-). Las siguientes secciones discuten mi comprensión de la integración y las recomendaciones para la configuración del proyecto / solución.

Si no está interesado en los detalles de cómo funciona la integración del control de fuente, puede pasar al final de esta respuesta donde resumo las respuestas a la pregunta de Weeble.

Descargo de responsabilidad : Las siguientes secciones son solo conjeturas basadas en mi experiencia empírica, sin embargo, he usado la técnica durante muchos años en muchos proyectos (cada proyecto tiene múltiples ramas experimentales / troncales / de mantenimiento / liberación, a veces incluso múltiples archivos de solución, sin problemas ) La desventaja es que tienes que actualizar manualmente los archivos del proyecto, pero la inversión de 2 minutos se amortiza a lo largo de la vida útil de un proyecto en mi humilde opinión :-).

Solución vs. Proyecto

Visual Studio utiliza información de enlace de control de origen desde el archivo de solución y cada archivo de proyecto durante la carga de la solución inicial. Esta información de enlace se almacena en el archivo name.suo (suponiendo que estamos usando name.sln como solución). Tenga en cuenta que los archivos suo están marcados con un indicador oculto para que no sean visibles en el explorador de archivos (a menos que anule el "Oculto"). opción de archivos y carpetas).

La forma más fácil de volver a vincularse al proveedor de control de origen si algo sale mal es eliminar el archivo suo apropiado y volver a abrir la solución. Después de que se haya creado el archivo suo, los cambios en los elementos <Scc *> no tienen ningún efecto.

Si durante la apertura de la solución inicial hay una discrepancia entre la información de enlace almacenada en el archivo de la solución y la información almacenada en el archivo del proyecto, Visual Studio intentará solucionarlo (a veces incluso solicitará su decisión de elegir si la información en la solución o el la información en el proyecto debe usarse como un "maestro" para resolver la discrepancia):

¿Por qué Visual Studio viola el principio DRY (Do not Repeat Yourself)? No tengo idea. Supongo que esto tiene razones históricas y está estrechamente relacionado con las necesidades de esa pesadilla llamada Visual Source Safe :-).

¿Cómo configurarlo "correctamente"?

Al agregar soluciones / proyectos nuevos o existentes a Perforce, siempre comienzo creando una solución en blanco (consulte la sección "Control de fuente en blanco"). Luego agrego proyectos a esta solución en blanco, uno tras otro. Los pasos difieren ligeramente en función de si el proyecto que se está agregando ya existe (consulte las secciones "Controlar la fuente de proyectos existentes (sin consolidar)" y "Controlar la fuente de proyectos existentes (encuadernados)" o necesito crear uno nuevo (consulte el Sección "Proyectos nuevos que controlan la fuente").

Fuente que controla una solución en blanco

Para agregar una nueva solución en blanco al control de origen, haga lo siguiente:

  1. Inicie Visual Studio, "Nuevo" -> "Proyecto ..." -> "Otros tipos de proyectos" -> "Solución en blanco"; complete el nombre y la ubicación de la solución, botón "Aceptar"
  2. "Archivo" -> "Control de fuente" -> "Agregar solución al control de fuente ..."
  3. En el cuadro de diálogo de conexión, ingrese el puerto del servidor P4, cliente y usuario (tenga en cuenta que la vista del cliente seleccionado debe incluir la ubicación que seleccionó en el paso 1)
  4. "Ver" -> "Informes pendientes" -> "Ingreso" -> en el cuadro de diálogo Enviar en lugar de presionar el botón "Enviar", use "Cancelar".
    Motivo : la acción "Ingreso" creará un nuevo archivo, "nombre.vssscc", luego agregará "nombre.sln" y "nombre.vssscc" a la lista de cambios predeterminada de Perforce; al cancelar el cuadro de diálogo de envío, mantendremos pendiente la operación de "agregar" y podremos editar los archivos antes de enviarlos a P4
  5. Cerrar Visual Studio

  6. Abra el archivo name.sln en su editor favorito (notepad, si está realmente desesperado :-)) y agregue dos nuevas líneas ( SccProjectName0 y SccProvider0 ) - el archivo de solución en blanco ahora debería tener una sección de control de origen de la siguiente manera:

    GlobalSection(SourceCodeControl) = preSolution SccNumberOfProjects = 1 SccLocalPath0 = . SccProjectName0 = Tutorial SccProvider0 = MSSCCI:Perforce/u0020SCM EndGlobalSection

    Los valores se deben elegir de la siguiente manera:

    • SccProjectName0 : una cadena arbitraria que se mostrará en el cuadro de diálogo "Cambiar control de fuente" como "Enlace de servidor". Este nombre se usa para determinar qué proyectos / archivos de solución pueden compartir la misma conexión de control de origen. Recomiendo no usar espacio para este nombre ya que las reglas de escape para espacios son diferentes en los archivos de solución y proyecto.
    • SccProvider0 : valor codificado "MSSCCI: Perforce / u0020SCM".
  7. Presente los dos archivos pendientes utilizando el cliente Perforce de su elección (p4.exe, P4Win, P4V)

Ahora puede probar los enlaces:

  1. Asegúrate de que Visual Studio esté cerrado
  2. Eliminar ** todos * los archivos excepto el nombre.sln (especialmente el nombre.suo)
  3. Abra Visual Studio y úselo para abrir name.sln
  4. Debe aparecer un cuadro de diálogo de conexión, usar el puerto / cliente / usuario apropiado y hacer clic en Aceptar
  5. El explorador de soluciones ahora debería mostrar el nodo de solución con un icono de superposición de candado:
  6. Ahora puede verificar el estado del control de fuente de la solución usando "Archivo" -> "Control de fuente" -> "Cambiar control de fuente ...": Nota: La columna "Enlace de servidor" muestra el valor que elegimos para "SccProjectName0".

Nuevos proyectos que controlan la fuente

Si está creando un proyecto completamente nuevo y desea comenzar a rastrearlo de inmediato en un depósito de Perforce, siga estos pasos:

  1. Abra la solución controlada por código fuente en Visual Studio
  2. "Archivo" -> "Agregar" -> "Nuevo proyecto ..." - seleccione el tipo de proyecto que está agregando, nombre y ubicación (la ubicación debe ser un subdirectorio del directorio donde está almacenado el archivo de la solución)
  3. "Archivo" -> "Guardar todo" (esto enviará todos los cambios en la memoria al archivo de la solución y al archivo del proyecto recién creado al disco)

  4. Edite manualmente el archivo de proyecto que acaba de crear con un editor de su elección (vamos, bloc de notas ¿OTRA VEZ? ;-)). Agregue los siguientes elementos de propiedad en un PropertyGroup (cualquier grupo de propiedades):

    <PropertyGroup> ... <SccProjectName>Tutorial</SccProjectName> <SccLocalPath>../..</SccLocalPath> <SccProvider>MSSCCI:Perforce SCM</SccProvider> ... </PropertyGroup>

    Los valores se deben elegir de la siguiente manera:

    • SccProjectName : este es el valor que se muestra en el cuadro de diálogo "Cambiar control de fuente" como "Enlace de servidor"; debe ser el mismo que el valor que utilizó para SccProjectName0 en una solución en blanco; si no es lo mismo, la solución y este proyecto no podrán compartir la misma conexión de proveedor de control de origen
    • SccLocalPath : ruta relativa al directorio de referencia (que se muestra en el cuadro de diálogo "Cambiar control de fuente" como " Enlace local"); porque recomiendo usar el directorio de soluciones como el directorio de referencia, esto es en efecto ruta relativa del directorio que contiene el archivo de proyecto al directorio que contiene el archivo de solución (mi ejemplo es almacenar proyectos en "(directorioDolución) /Source/ProjectName/projectName.csproj", por lo tanto la ruta relativa es "dos niveles arriba")
    • SccProvider - valor codificado "MSSCCI: Perforce SCM"; esto se usa para determinar qué proveedor SCCAPI son los valores de enlace Scc * válidos para

  5. Cambiar de nuevo a Visual Studio; debería detectar automáticamente que el archivo del proyecto se ha actualizado externamente y ofrecerle volver a cargarlo (si no, descargue y vuelva a cargar el proyecto manualmente)

  6. "Ver" -> "Entradas pendientes"
  7. "Check In" -> Recomiendo hacer clic derecho en el archivo .vssscc (nombre de la solución) y seleccionar "Revertir si no se modifica" (aunque Visual Studio lo abre para editarlo, no cambia); proporcionar descripción y enviar el cambio

Para verificar que el proyecto recién agregado está vinculado correctamente, puede seguir estos pasos:

  1. Asegúrate de que Visual Studio esté cerrado
  2. Delete (solutionName) .suo file así como MSSCCPRJ.SCC (en el directorio de la solución)
  3. Abra Visual Studio y úselo para abrir (solutionName) .sln
  4. Debe aparecer un cuadro de diálogo de conexión, usar el puerto / cliente / usuario apropiado y hacer clic en Aceptar
  5. El explorador de soluciones ahora debería mostrar el nodo del proyecto con un icono de superposición de candado:

  6. Ahora puede verificar el estado del control de fuente de la solución usando "Archivo" -> "Control de fuente" -> "Cambiar control de fuente ...":

    Una cosa a tener en cuenta acerca de esta captura de pantalla de estado es que cuando seleccioné la fila de solución, todas las filas restantes también fueron "seleccionadas" (resaltado azul). Esto se debe a que todas esas entradas tienen el mismo "enlace de servidor" + "enlace local" y, por lo tanto, comparten la misma conexión proveedor-control-proveedor (P4).

    También tenga en cuenta que "Ruta relativa" para ambos proyectos tiene dos niveles, y son relativos a la misma "Enlace local" - el directorio donde reside el archivo de solución.

Proyectos que controlan la fuente (sin consolidar)

Si tiene proyectos existentes que aún no se han utilizado en ninguna otra solución de Perforce, siga estos pasos para agregarlos a Perforce (es decir, importar proyectos que no hayan sido controlados por fuente antes (descargas de Internet, etc.) o que estén usando un control fuente diferente proveedor (Visual Source Safe, etc.).

  1. Copie el proyecto en la ubicación adecuada
  2. Limpiar enlaces de control de fuente existentes (si los hay):
    • Elimine enlaces existentes de archivos de proyecto, es decir, todas las propiedades que comiencen con "Scc"
    • Eliminar el archivo (projectName) .vspscc en el mismo directorio que el archivo del proyecto (si corresponde)
  3. Abra la solución controlada por código fuente en Visual Studio
  4. "Archivo" -> "Agregar" -> "Proyecto existente ..." - navegue hasta el proyecto (la copia que creó en el paso 1)
  5. "Archivo" -> "Guardar todo" (esto confirmará todos los cambios en la memoria en el archivo de la solución)
  6. Siga los pasos 4 a 7 de "Nuevos proyectos que controlan la fuente" (es decir, ahora agregará elementos de propiedad "Scc *" en un grupo de propiedades )

Los pasos de verificación son exactamente los mismos que en la sección "Proyectos nuevos que controlan la fuente".

Proyectos (vinculados) que controlan la fuente

Si tiene proyectos que ya han estado vinculados a Perforce utilizando la técnica que se discute aquí y desea usarlos en una solución diferente (nueva sucursal, solución alternativa que reutilice el proyecto, etc.) utilice los siguientes pasos:

  1. Integre el proyecto en la ubicación deseada
  2. Abra la solución controlada por código fuente en Visual Studio
  3. "Archivo" -> "Agregar" -> "Proyecto existente ..." - navegue hasta el proyecto creado en el paso 1 a través de la integración
  4. "Ver" -> "Informes pendientes" -> "Ingreso" - agregar descripción y enviar

Resumen

  • La información de enlace de control de origen se almacena tanto en solución como en proyectos, debe estar sincronizada (si no, Visual Studio intentará corregir cualquier discrepancia)
  • Siempre trato a los archivos de proyecto como la fuente principal de información de enlace y archivos de solución como archivos desechables que se pueden recrear fácilmente por primera fuente, controlando una solución en blanco y luego agregando los proyectos deseados
  • El archivo de la solución siempre debe tener valores válidos de SccProvider0 y SccProjectName0 (deben agregarse manualmente con las nuevas versiones de los complementos de P4SCC)
  • Los archivos de proyecto siempre deben tener valores válidos de SccProjectName (preferiblemente igual que SccProjectName0 ), SccLocalPath y SccProvider (también deben editarse manualmente ya que los valores predeterminados de P4SCC no son buenos)

También estoy incluyendo respuestas a sus preguntas originales:

¿Qué sucede cuando haces "Cambiar el control de código fuente" y vincula proyectos? ¿Cómo decide Visual Studio qué incluir en el proyecto y en los archivos de la solución?

Esto actualiza elementos "Scc *" en un archivo de proyecto que estás reencuadernando; el archivo de la solución también se actualiza para que esté sincronizado con los enlaces del archivo del proyecto

¿Qué sucede cuando haces "Abrir desde el control de código fuente"?

Le permite elegir la solución que le gustaría abrir. Después, todos los proyectos incluidos en la solución se sincronizan automáticamente a la cabeza. Encuentro que esta característica no es muy útil en Perforce World, donde tienes que crear un cliente de todos modos y lo más probable es que estés sincronizando este cliente desde un P4V / P4Win / P4 en lugar de confiar en Visual Studio. Esto fue algo útil en el mundo de Visual Source Safe donde no había concepto de vistas y usted estaba definiendo dónde se encuentra el repositorio en la hora de salida.

¿A qué se refiere esta carpeta de "conexión" a la que se refieren SccLocalPath y SccProjectFilePathRelativizedFromConnection? ¿Cómo lo elige Visual Studio / Perforce?

Esta es la contabilidad de Visual Studio. Se determina en función de los enlaces en cada archivo de proyecto (supongo que, en teoría, si un archivo de proyecto pierde información vinculante por algún motivo, podría ser reconstruido a partir de la información de la solución ...)

¿Hay alguna forma recomendada de hacer que los enlaces de control de origen continúen funcionando incluso cuando se crea una nueva rama de la solución?

Espero que las secciones anteriores te den una idea de una manera que me está funcionando muy bien :-).

Estamos usando Perforce y Visual Studio. Cada vez que creamos una sucursal, algunos proyectos no estarán sujetos al control de origen a menos que usemos "Abrir desde el control de código fuente", pero otros proyectos funcionan independientemente. De mis investigaciones, sé algunas de las cosas involucradas:

En nuestros archivos .csproj, existen estas configuraciones:

  • <SccProjectName>
  • <SccLocalPath>
  • <SccAuxPath>
  • <SccProvider>

A veces están configurados para "SAK", a veces no. Parece que las cosas funcionan más si dicen "SAK".

En nuestro archivo .sln, hay configuraciones para muchos de los proyectos:

  • SccLocalPath #
  • SccProjectFilePathRelativizedFromConnection #
  • SccProjectUniqueName #

(El # es un número que identifica cada proyecto.) SccLocalPath es una ruta relativa al archivo de solución. A menudo es ".", A veces es la carpeta en la que se encuentra el proyecto, y algunas veces es ".." o ".. / ..", y parece ser malo señalar una carpeta encima del carpeta de la solución. El relativizado es una ruta de esa carpeta al archivo del proyecto. Faltará por completo si SccLocalPath apunta a la carpeta del proyecto. Si SccLocalPath tiene "...", esta ruta puede incluir nombres de carpeta que no son los mismos entre las ramas, lo que creo que causa problemas.

Entonces, para finalmente llegar a los detalles que me gustaría saber:

  • ¿Qué sucede cuando haces "Cambiar el control de código fuente" y vincula proyectos? ¿Cómo decide Visual Studio qué incluir en el proyecto y en los archivos de la solución?
  • ¿Qué sucede cuando haces "Abrir desde el control de código fuente"?
  • ¿A qué se refiere esta carpeta de "conexión" a la que se refieren SccLocalPath y SccProjectFilePathRelativizedFromConnection? ¿Cómo lo elige Visual Studio / Perforce?
  • ¿Hay alguna forma recomendada de hacer que los enlaces de control de origen continúen funcionando incluso cuando se crea una nueva rama de la solución?

Agregado junio de 2012: No uso Perforce más, por lo que no puedo responderlo, pero eche un vistazo a la respuesta de KCD a continuación. Aparentemente hay un nuevo plugin P4 VS en desarrollo. ¡Con suerte, debería aclarar todo este lío!

Después de experimentar con la respuesta muy informativa de Milan Gardian, creo que puedo proporcionar una solución más simple para que funcione bastante bien.

Como mencionó Weeble, los valores SAK funcionan bien cuando todo lo demás está configurado correctamente, y a menudo son los valores predeterminados (pero creo que depende del tipo de proyecto que sea). Si no aparecen en su proyecto, simplemente pegue en este grupo de propiedades.

<PropertyGroup> <SccProjectName>SAK</SccProjectName> <SccProvider>SAK</SccProvider> <SccAuxPath>SAK</SccAuxPath> <SccLocalPath>SAK</SccLocalPath> </PropertyGroup>

Agregue estas dos líneas al * .sln en SourceCodeControl GlobalSection. Siempre que los archivos del proyecto tengan valores SAK, deben heredar los nombres de la solución.

SccProjectName0 = Perforce/u0020Project SccProvider0 = MSSCCI:Perforce/u0020SCM

Los archivos * .vssscc, * .vspscc o * .SCC no se deben registrar (aunque se generarán cuando se abra la solución).

El soporte para cambiar el nombre de un archivo o moverlo a un nuevo directorio de carpetas es terrible y doloroso si se usa la integración de plug-ins de Visual Studio P4. No existe ninguna función incorporada que avise a P4 para que cambie el nombre del archivo o que se haya movido.

El problema es que renombrar un archivo requiere no solo actualizar el archivo de proyecto de VS asociado, sino que también se debe informar a Perforce del cambio si desea mantener un historial de revisión adecuado.

Actualmente, no veo una manera de hacer ambas cosas en una sola operación si utilizo la integración VS. En cambio, tienes que:

  1. renombrar / mover el archivo desde dentro del cliente de Perforce
  2. eliminar la referencia de nombre de archivo anterior en el archivo de proyecto dentro de VS
  3. agregue la nueva referencia de nombre de archivo en el archivo de proyecto dentro de VS
  4. envía tus cambios

Si utiliza un proceso de compilación de integración continua y envía los cambios en cualquier momento antes del último paso, se garantiza que la compilación estará rota.

El problema magnifica significativamente la cantidad de archivos que requieren cambio de nombre o movimiento. Este no es un proceso suave en absoluto.

El uso de Perforce con Visual Studio se puede simplificar mediante el uso de la variable de entorno P4CONFIG.

Básicamente vas a Visual Studio, Herramientas -> Opciones -> Control de Fuente -> Configuración de Plug-in, botón Avanzado. Esto abrirá un diálogo de configuración de Perforce específico para la integración de SCC. Pase a la pestaña Conexión y marque el botón de opción titulado ''Enlazar el área de trabajo que coincida con la configuración de su entorno Perforce''. Esto dirá forzosamente que prefiera usar la variable de entorno P4CONFIG para determinar el entorno en el que se encuentra. Este mismo diálogo existe en P4V bajo Editar -> Preferencias, pero solo afecta el comportamiento de p4v.

Cómo configuras la variable de entorno P4CONFIG depende de ti hasta cierto punto. Me gusta que tengan el mismo nombre en todas partes, así que establecí una variable de entorno P4CONFIG para todo el sistema para buscar un archivo llamado p4config.cfg. Este archivo es solo un archivo de estilo ini, donde puede asignar otras variables como P4USER, P4CLIENT, P4HOST, etc. Perforce buscará este archivo en el directorio actual y en todos los directorios principales hasta que encuentre uno. Básicamente, coloque este archivo en el directorio raíz de su ubicación de clientes en donde está asignada su cliente, y déjelo en blanco.

Este enfoque reduce en gran medida la cantidad de "corrección" que la configuración de SCC necesita en el estudio visual para funcionar. (Las fijaciones SAK funcionan bien, etc.)

Si después de sincronizar el código de forzosamente por primera vez o con una estructura de directorios completamente limpia, y al obtener un cuadro de diálogo quejándose de que forzosamente desea trabajar sin conexión temporalmente o eliminar enlaces, todavía queda algo de edición por hacer. En primer lugar, el archivo .sln debe modificarse para que sepa que sln tiene enlaces SCC por sí mismo. Esto se hace asegurándose de que los siguientes campos se coloquen justo después de SccNumberOfProjects en el archivo .sln.

SccProjectName0 = Perforce/u0020Project SccProvider0 = MSSCCI:Perforce/u0020SCM

Todos los proyectos individuales deberían funcionar bien con ''enlaces SAK'' predeterminados siempre que esté utilizando el enfoque P4CONFIG. Arreglar esto debería permitir a Perforce trabajar perfectamente desde una sincronización limpia, y también eliminar la generación de MSSCCPRJ.SCC en cada uno de los directorios del proyecto.

Este no es un problema de Perforce, es un problema de Visual Studio. El ridículo requisito de que los archivos fuente se modifiquen para permitir que Visual Studio comprenda que hay una herramienta SCM en uso es estúpido.

La respuesta simple es ''dejar de usar la integración de control de fuente de Visual Studio''. Simplemente apesta. Incluso con TFS simplemente apesta.

Si desea poder verificar desde Visual Studio, solo cree una herramienta personalizada. Una simple llamada a ''edición p4'' con la variable VS adecuada es todo lo que necesita. ¿Quieres revertir un archivo? La misma idea ... llamar a p4 revertir con la variable adecuada. Hecho.

Use p4v para administrar sus necesidades de control de fuente (envíos, historial, diffs, etc.) Visual Studio funciona como un editor de código fuente. Apesta como una interfaz SCM.

La publicación de Milán está bien investigada y bien escrita, pero su longitud demuestra sin lugar a dudas que el modelo P4SCC está roto. Almacenar información de enlace de control de fuente dentro de los archivos de proyecto y solución es ridículo. Hacer cumplir (a través de sccprojectname) que un proyecto sea parte de una sola solución es igualmente ridículo.

Además, P4SCC tiene un costo de rendimiento tremendo en una solución grande, ya que recupera información del control de origen para cada archivo al inicio, y mantiene ese estado en la memoria durante toda la sesión de desarrollo. Crea archivos extra en forma de archivos .vsscc y vssscc libres de información para admitir alguna característica de SCC que (AFAICT) Perforce no utiliza.

La integración ideal de Perforce se ve así:

  • Si creo una nueva solución, proyecto o elemento de proyecto, ejecute ''p4 add''.
  • Si cambio un archivo, ejecute ''p4 edit''.
  • Algunas barras de herramientas / integración de menú de contexto para el historial de revisión, gráfico de revisión, timelapse / culpa y ''mostrar en P4 gui''.
  • (Es bueno tenerlo) Si cambio el nombre de un archivo que existe en el depósito, ejecute ''p4 integrate'' y ''p4 delete''. Si cambio el nombre de un archivo abierto para agregar, ejecute ''p4 revert'' y ''p4 add''.
  • Eso es todo

Nos hemos alejado completamente del P4SCC y sus extrañas necesidades y cargas. En cambio usamos NiftyPerforce . Hay algunos errores, pero nos parece que trabajar con estos errores es mucho menos frustrante que solucionar los defectos de diseño en el modelo VS.CC de Perforce.

Muy pobremente. Sé que esa no es la respuesta a sus preguntas que estaba buscando (¿en el futuro, quizás podría limitar el enfoque?), Pero la integración del control de fuente con Visual Studio simplemente apesta. La razón es que todos tienen que usar la terrible interfaz SCC de Microsoft. ¡Es patética! ¡Ponen información de control de fuente en los archivos del proyecto! ¿Por qué harían eso?

Simplemente abandone la integración de Visual Studio y use el cliente Perforce. No es tanto trabajo extra. No puede perder 30 segundos por día para cambiar al cliente de Perforce y registrar / retirar los archivos desde allí.

Para mantener esto actualizado, el plugin P4VS se reescribió alrededor de 2012

Ahora puede realizar toda su interacción diaria con Perforce de forma natural, como ingresar el código y ver el historial de archivos, directamente desde el IDE.

Si eres un usuario avanzado que busca un poco más, P4VS no defraudará. P4VS es totalmente compatible con Perforce Streams, y Stream Graph es accesible desde IDE, junto con Time-lapse View y Revision Graph. Si es responsable de la administración de la sucursal, también puede fusionarse desde P4VS.

Y, si trabaja de forma remota o quiere hacer una pequeña bifurcación privada, P4Sandbox se puede configurar a través de P4VS.

Puedo responder el último.

Para hacer que los enlaces de control de fuente funcionen incluso cuando creas una nueva rama, sigue una estructura jerárquica estricta:

/Solution /library1 /library2 /product1 /product2 /subsolution /sublibrary1 /subproduct1

Cada archivo debe estar en exactamente un .vcproj. Puede tener múltiples .vcproj en el mismo directorio, pero si comparten archivos, los archivos compartidos deben ir a su propio archivo .vcproj.

Si eres implacable en esto, todas las cosas Scc serán de ruta relativa, por lo que una nueva rama funcionará (porque solo cambia el directorio superior).