Совместное использование одного и того же файла между различными проектами

Question

Для контроля версий мы в настоящее время используем Visual Source Safe и планируем перейти на другую систему контроля версий (SVN, Mercurial, Git).

В настоящее время мы довольно активно используем функцию общего файла в Visual Source Safe. Это позволяет нам обмениваться кодом между дизайном и временем выполнения одного продукта, а также между несколькими продуктами.

Например:

**Product One**
  - Design
     Login.cpp
     Login.h
     Helper.cpp
     Helper.h
  - Runtime
     Login.cpp
     Login.h
     Helper.cpp
     Helper.h

**Product Two**
  - Design
     Login.cpp
     Login.h
  - Launcher
     Login.cpp
     Login.h
  - Runtime
     Login.cpp
     Login.h

В этом примере Login.cpp и Login.h содержат общий код, который нужен всем нашим проектам, Helper.cpp и Helper.h используются только в Product One. В Visual Source Safe они разделяются между конкретными проектами, что означает, что всякий раз, когда файлы обновляются в одном проекте, они обновляются в любом проекте, с которым они совместно используются.

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

После исследования альтернатив Visual Source Safe кажется, что большинство систем контроля версий не имеют представления об общих файлах, вместо этого они, похоже, используют идею вложенных репозиториев. (https://www.mercurial -scm.org / wiki / subrepos http://svnbook.red -bean.com / ru / 1.0 / ch07s03.html )

Мой вопрос (после всего этого) о том, какие наилучшие практики для достижения этого используют другие системы контроля версий?

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

   Product One

   • Дизайн Login.cpp Login.h
   • время выполнения Login.cpp Login.h
   • Общие Helper.cpp Helper.h

Это все еще оставляет, что делать с Login.cpp и Logon.h

2. Должны ли общие файлы быть перемещены в их собственный репозиторий и затем скомпилированы в lib или dll? Это сделает исправление ошибок более трудоемким, поскольку проекты lib придется редактировать и затем перестраивать.

3. Должны ли мы использовать внешние или вспомогательные репозитории?

4. Должны ли мы объединить наши проекты (т.е. время выполнения, дизайн и модуль запуска) в один большой проект?

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

Или, может быть, мы единственные люди, которые делают это ...?

Кроме того, мы используем Visual Studio для всех наших вещей.

Спасибо.

Answer 1

Я могу говорить только с точки зрения SVN, но довольно часто файлы, используемые в нескольких проектах, хранятся в отдельном модуле (SVN имеет понятие модулей, я думаю, это то, что вы имеете в виду, когда имеете в виду sub хранилища).

Я бы хотел сделать так, чтобы общий код, необходимый для нескольких проектов, был зарегистрирован как отдельный модуль. Если вы называете этот модуль Design, а два других ваших продукта отмечены в SVN как ProductOne и ProductTwo, то все, что вам нужно, это проверить модуль Design и ProductOne, чтобы зависимость ProductOne зависела от Design для компиляции.

В Visual Studio рабочее пространство называется решением, которое может содержать более одного проекта. Таким образом, вы можете иметь все три модуля в качестве проектов и сделать проект ProductOne зависимым от проекта Design. Это так просто.

Answer 2

A голос за Mercurial !

Учитывая это, я согласен с другими постерами, что вы должны перетаскивать любые дублирующиеся файлы в общую папку. Если вы используете Mercurial, у меня будет библиотека lib или общий каталог, который является хранилищем Mercurial, а затем отдельная папка / хранилище для каждого проекта и его уникальный код.

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

Надеюсь, это поможет!

Answer 3

В прошлом я перешел из аналогичной ситуации (C ++, Visual Studio, VSS) в SVN. Мы решили поделиться исходным кодом между различными проектами с помощью svn: externals. Это сработало, но было не очень красиво. Особенно с ветками и тегами, это может стать очень болезненным.

Я бы настоятельно рекомендовал перенести общий код в отдельный проект и поделиться им на уровне lib. Отладка и совместная разработка могут работать одинаково хорошо, если тщательно продумать процесс разработки и сборки. Кроме того, перемещение общего кода в отдельный проект в системе управления версиями не обязательно означает, что он должен поддерживаться полностью независимо от остальной части вашего кода. Это скорее вопрос окружающего процесса и управления проектами. С другой стороны, этот сценарий позволяет независимо поддерживать библиотеку. В вашей текущей ситуации у вас даже нет такого выбора.