La mejor práctica para administrar SVN con una solución con múltiples proyectos involucrados

Antes de comenzar, lo siguiente se basa en el conocimiento adquirido a través del uso de los proyectos web TortoiseSVN 1.6.x y ASP.NET con Visual Studio 2008 como ejemplo.

Caso de estudio

Digamos, en un escenario de días felices, una estructura de repository de subversión típica puede ser similar a:

/trunk /Solution1 /ProjectA /ProjectB /ProjectC /tags /Solution1 /version_1.0-rc /version_1.1 /branches /users /travis /Solution1 /john /Solution1 
  • Solution1 es una Solution1 Visual Studio que contiene 1 a muchos proyectos de Visual Studio.
  • Los usuarios están trabajando en su propia twig de solución, fusionándose de nuevo al tronco de vez en cuando. Nadie está trabajando directamente en el maletero.
  • Las tags se crean desde el tronco siempre que haya una publicación pública.

Sin embargo, en el mundo real, la estructura del proyecto no es tan simple, ya que muchos proyectos de Visual Studio se comparten entre varias de las soluciones de Visual Studio. El repository se parece más a:

 /trunk /CandyLand /Candy.Web.Pages /Candy.Web.Services /Candy.Tests /LollyApp /Lolly.App.WinForm /Lolly.App.Services /Lolly.Tests /Fundamental /Fundamental.BusinessObjects /Fundamental.DataAccess /Components.ExternalLibraries /Subsonic-2.2 /Moq-3.1 /Lucene.NET-2.0 

Donde en el ejemplo hay 2 productos Candy y Lolly , y los componentes compartidos (proyectos de Visual Studio, DLL) estarán en Fundamental carpetas Fundamental y Components.ExternalLibraries respectivamente.

Supongamos que funciona fuera de trunk, para poder trabajar en CandyLand Visual Studio Solution, necesito verificar sus files del repository, así como los componentes necesarios, para que la estructura de la solución se vea algo así como:

 + CandyLand + Candy.Web.Pages + Candy.Web.Services + Candy.Tests + Fundamental.BusinessObjects + Fundamental.DataAccess + Subsonic-2.2 + Moq-3.1 

Mover las cajas y anidar las carpetas juntas puede ser un poco molesto, usamos scripts por lotes para hacer esto por nosotros.

Problema

Me pareció imposible ramificarme en esta circunstancia, donde las sucursales de usuarios solo contendrán proyectos en soluciones ramificadas y no en proyectos compartidos.

Lo mismo con el labeldo, no puedo crear una label que contenga una instantánea de revisión de la solución del producto y sus componentes compartidos.

.

¿Voy en la dirección incorrecta? ¿He hecho que este repository sea demasiado difícil de administrar?

Use svn: externals para include las carpetas en Candyland.

En el ejemplo a continuación, el * marca un external:

 + CandyLand + Candy.Web.Pages + Candy.Web.Services + Candy.Tests * Fundamental.BusinessObjects * Fundamental.DataAccess * Subsonic-2.2 * Moq-3.1