Организация решений в SVN - PullRequest
Новая
       22

Организация решений в SVN

0 голосов
/ 01 сентября 2011

Как сохранить несколько связанных решений / проектов Visual Studio, организованных в SVN-репозитории (или нескольких репозиториях)?

Например, у меня есть два приложения (решения), которые совместно используют несколько общих проектов: 

+ Application_1
  - Company.Core
  - Company.Connections
  - Company.Data
  - Company.A1.DAL
  - Company.A1.BL
  - Company.A1.UX

+ Application_2
  - Company.Core
  - Company.Connections
  - Company.Data
  - Company.A2.DAL
  - Company.A2.BL
  - Company.A2.UX

Правильно нет, и Application_1, и Application_2 совместно используют один и тот же корень SVN , поскольку они используют общие проекты: 

/svnroot
   /common
      /trunk
         /Company.Core
         /Company.Connections
         /Company.Data
   /app1
      /trunk
         /A1.DAL
         /A1...
   /app2
      /trunk
         /A2.DAL
         /A2...

Причина этого заключается в том, чтоЭто гарантирует, что в каждом выпуске есть последние доступные сборки из общей папки и что проверки всегда согласованы на каждой машине.

Итак, я хотел бы знать следующее:

  • Должно ли каждое решение иметь свой собственный репозиторий?
  • Если да, как я могу поделиться общими проектами и убедиться, что они актуальны?
  • Добавлять ли общие сборки как уже построенные зависимости (.dll) и фиксировать их для каждогохранилище решений отдельно?Как мне автоматизировать такие сборки?

1 Ответ

2 голосов
/ 01 сентября 2011

Как вы настраиваете свои репозитории, полностью зависит от вас и как это работает для вашей организации.Я видел несколько подходов к этому, и за эти годы не нашел твердого совета.

Редактировать

Эта последняя часть была написана плохо.Под «отсутствием твердого совета» я понимал, что ни один из советов не говорит: «Вы должны структурировать свой репозиторий следующим образом ...» Весь совет представлен как «это то, что работает для нас», и каждый из этих способоввыкладка репо работает для них , и макеты варьируются.Так что я действительно имел в виду «нет твердого совета, который применим к каждой организации».

end edit

Однако, ваш репозиторий структурирован очень близко к нашему.У нас есть сотни проектов и несколько узлов от корня.Все они находятся в одном репозитории.

Как и у вас, у нас есть общий каталог, в котором хранятся проекты с общими функциями, которые мы добавляем в качестве ссылки на проекты в решениях в других узлах.Это то, что мы придумали после многих реструктуризаций в процессе проб и ошибок, и это hth, который работает для нас, поэтому я бы дал вам большой обзор вашей структуры.

Чтобы ответить на вашконкретные точки

  • Я думаю, что у вас должен быть один репозиторий со структурой, которую вы описали, выходящей из ствола.
  • Это позволяет вам получить код за одну проверку, гарантируя, что все легкоподдерживать и поддерживать в актуальном состоянии.Просто добавьте ваши ссылки, поскольку все находятся в одном репо.
  • Наконец, наше общее правило: всегда добавляйте вашу ссылку на проект, где это необходимо, и НЕ проверяйте в двоичных файлах, КРОМЕ ТОГО, где вам нужно общееdll и у вас нет источника (например, компонента 3-ей части).Например, у нас есть Microsoft.AntiXss dll и Idunno.Anti-Csrf dll в «общих dll» в нашей «общей» папке.

В качестве примечания, эта структура также привела кпростое время настройки сервера сборки.Когда мы настроили наш сервер сборки CruiseControl.NET, он сделал одну проверку и собрал все, указав на файлы .sln, как в Visual Studio.имея его в одном репо и следуя рекомендациям, которые я только что изложил, очень легко настроить наши сборки.

...