Для контроля версий в настоящее время мы используем 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 используются только в первом продукте. В Visual Source Safe они совместно используются конкретными проектами, что означает, что всякий раз, когда файлы обновляются в одном проекте, они обновляются в любом проекте, с которым они совместно используются.
Это простой пример, но, надеюсь, он объясняет, почему мы используем общую функцию: чтобы уменьшить количество дублированного кода и гарантировать, что после исправления ошибки все проекты автоматически получат доступ к новому исправленному коду.
После изучения альтернатив Visual Source Safe выяснилось, что в большинстве систем контроля версий нет идеи общих файлов, вместо этого они используют идею подрепозиториев. ( https://www.mercurial-scm.org/wiki/subrepos http://svnbook.red-bean.com/en/1.0/ch07s03.html< /а>)
Мой вопрос (после всего этого) о том, какие лучшие практики для достижения этого используют другие системы контроля версий?
Должны ли мы реструктурировать наши проекты так, чтобы две копии файлов не существовали, а вместо них использовался включаемый каталог? например
Первый продукт
- Design Login.cpp Login.h
- Во время выполнения Login.cpp Login.h
- Общий Helper.cpp Helper.h
Это все еще оставляет, что делать с Login.cpp и Logon.h
Должны ли общие файлы быть перемещены в их собственный репозиторий, а затем скомпилированы в lib или dll? Это сделало бы исправление ошибок более трудоемким, поскольку проекты библиотеки пришлось бы редактировать, а затем пересобирать.
Должны ли мы использовать внешние или подрепозитории?
Должны ли мы объединить наши проекты (т. е. среду выполнения, дизайн и программу запуска) в один большой проект?
Любая помощь будет оценена по достоинству. У нас есть ощущение, что дизайн нашего проекта развивался на основе инструментов, которые мы использовали, и теперь, когда мы думаем о переключении инструментов, нам трудно понять, как мы можем лучше всего изменить наши методы.
Или, может быть, мы единственные, кто этим занимается...?
Кроме того, мы используем Visual Studio для всех наших вещей.
Спасибо.
