Блог

Я унаследовал очень неорганизованную базу данных VSS, и мне нужно ее очистить. Прежде чем я завершу свою реорганизацию, я хотел бы получить некоторые рекомендации, чтобы я не совершал подобных ошибок, как предыдущий человек. Я собираюсь перенести все в новый экземпляр VSS и начать все заново. Историческая информация не вызывает беспокойства, поэтому понятно, что новая установка не будет включать историю предыдущих версий. (При необходимости будет доступна текущая база данных VSS.)

В настоящее время мы используем Visual Studio 2005 и Visual Source Safe 2005. Мы перейдем на VS2010 и, возможно, TFS, но сначала первые шаги.

У нас есть три ASP.NET продукты, каждый из которых совместно использует несколько библиотек. Вот базовая структура проектов:

 PRODUCT 1  
    References:  
        Library 1  
          References:  
            Library 4  
            Library 5  
        Library 2  
        Library 3  

PRODUCT 2  
    References  
        Library 1  
            References:  
                Library 4  
                Library 5  
        Library 3  
        Library 6  

PRODUCT 3  
    References  
        Library 5  
        Library 3  
  

В качестве первого шага у меня есть все продукты и библиотеки, «не связанные» с VSS, и я структурировал их по папкам следующим образом. (Есть 3 разработчика, и мы все настроим одинаковую структуру папок на наших компьютерах.)

 C:SourceProductsProduct1  
C:SourceProductsProduct2  
C:SourceProductsProduct3  
C:SourceLibrariesLibrary1  
C:SourceLibrariesLibrary2  
...  
C:SourceLibrariesLibrary5  
  

Каждый продукт и каждая библиотека имеют свое собственное решение; ссылки на проекты используются для всех библиотек, на которые даны ссылки. Например, решение для ПРОДУКТА 1 включает ссылки на проекты для библиотек 1, 2, 3, 4 и 5. Решение для библиотеки 1 содержит ссылки на проекты для библиотек 4 и 5 и так далее. На этом этапе все строится.

Вопрос: Является ли обычной практикой для ПРОДУКТА 1 включать ссылки на проекты для библиотек 4 и 5, даже если он не ссылается на них напрямую (хотя один из его ссылочных проектов делает это)?

Я планирую настроить параллельную структуру в VSS:

 $ProdcutsProduct1  
...  
$LibrariesLibrary5  
  

Вопрос: является ли это логической структурой для использования? Если нет, что мне следует сделать по-другому.

Заранее спасибо за ваш вклад.

Darvis

Вопрос: Является ли обычной практикой для ПРОДУКТА 1 включать ссылки на проекты для библиотек 4 и 5, даже если он не ссылается на них напрямую (хотя один из его ссылочных проектов делает это)?

Да, это так, это даже требуется для определенных задач, таких как анализ кода в VS2010. Процесс сборки в любом случае исключит любую непосредственно неиспользуемую ссылку (это не причина не очищать ее, но поддерживается, что не все перечисленные ссылки на проекты используются непосредственно при сборке проекта).

Если вы работаете в VB.NET , вы можете автоматически очищать ссылки (но вы можете легко нарушить возможности анализа кода, и я сталкивался со случаями, когда это просто плохо работало), в C # возможность очистки ссылок на проекты не встроена (некоторые (несвободные) плагины делаютэто похоже на Resharper)

Вопрос: является ли это логической структурой для использования? Если нет, что мне следует сделать по-другому.

(Возможно, это должен быть отдельный вопрос о программистах, поскольку он довольно субъективен, но я все равно отвечу :))

Я не вижу никаких проблем в вашей логике. Лично я не разделяю библиотечные проекты и исполняемые проекты. Это просто проекты. Это действительно вопрос личных предпочтений, другие разделили бы его по клиентам, платформам и т. Д. Но пока люди могут видеть логику того, что вы делаете, и я не думаю, что вы столкнетесь с какими-либо проблемами при использовании VSS.