0

В настоящее время мы разрабатываем несколько более крупный проект C#. Однако мы боремся со структурой внутри Visual Studio.Управление проектами Visual C#

Решение содержит несколько проектов, которые зависят от одного проекта «».

e.g.: 

Solution  
- Base Objects 
    - Project A 
    - Project B 

Теперь мы хотим работать на одном «мастер„- версия, но и быть в состоянии создать несколько специализированных версий, которые не затронуты изменениями в“мастер» - версии.
(Но мы также хотим, чтобы обновить другие версии, когда «мастера». - версия изменен)

e.g.: 
Master 1.0 -> Master 1.1 -> Master 1.2 
        | Update Test Project? 
        V 
Test 1.0  Test 1.1 

(Мы в настоящее время используем AnkhSVN и работали с Team Foundation в прошлом.)
  1. Что мы должны помнить о нашей проектной архитектуре?
  2. Является ли AnkhSVN/Team Foundation правильным решением?
    (Есть несколько людей, работающих над проектом)
  3. Если да, то, как мы организуем нашу ствола/ветви
    (один ствол для каждого проекта, или держать хозяин, как ствола?)
  4. Как мы можем обновить наши специализированные версии, без , переписывая собственные изменения?
+0

значит 'проект' в визуальной студии смысле, или смысл управления проектом? – Ewan

+0

Проект как в управлении, я ссылаюсь на VS- «Project» в качестве решения. – MIT

+0

У меня, вероятно, есть решение для каждого проекта, включая базу, а затем следуйте [Стратегии филиала Microsoft] (https://msdn.microsoft.com/en-us/library/bb668955.aspx).Всякий раз, когда вам нужно работать над проектом с определенной версией базы, вы можете развить их оба одновременно. Когда изменения будут выполнены, объедините изменения в магистральные решения. –

ответ

0

Я бы посоветовал вам попробовать git. Распределенное управление источником имеет ряд преимуществ, вы можете прочитать о том, даже здесь: Using Git with Visual Studio Хорошо мечение и ветвления, а также Sourcetree очень хороший визуальный инструмент для работы с VS и мерзавцем: http://www.sourcetreeapp.com/

+0

Выглядит интересно, мы рассмотрим ее. Спасибо ^^ – MIT

0

Похоже, у вас есть " версии для каждого клиента. Если это так, то управление ветвлением/источником поможет вам только так. ветви функций и т. п. предназначены для решения проблемы разработки функций для одного продукта, а не для обслуживания нескольких похожих продуктов.

Я бы посоветовал вам структурировать программное обеспечение, используя шаблон вставки. Здесь у вас есть приложение «shell», в котором размещено несколько плагинов. каждый использует (или имеет возможность обновления) последней версии приложения оболочки. но каждый клиент может иметь разные или специализированные плагины, каждый из которых поддерживается как отдельное решение.

мастер оболочки -> функция ветви v2

плагин A -> плагин A v2

плагин B

и т.д.

 Смежные вопросы

  • Нет связанных вопросов^_^