Контроль версий: ад нескольких версий, синхронизация файлов

Question

Хотелось бы узнать, как вы обычно справляетесь с этой ситуацией:

У меня есть набор служебных функций. Say..5..10 файлы. И технически это статическая библиотека, кроссплатформенная - проект SConscript / SConstruct plus Visual Studio (не решение).

Эти служебные функции используются в нескольких небольших проектах (15+, число увеличивается с течением времени). Каждый проект имеет копию нескольких файлов или всей библиотеки, а не ссылку на одно центральное место. Иногда проект использует один файл, два файла, некоторые используют все. Обычно служебные функции включаются в качестве копии каждого файла и SConscript / SConstruct или Visual Studio Project (в зависимости от ситуации). Каждый проект имеет отдельный репозиторий git. Иногда один проект является производным от другого, иногда это не так. Вы работаете с каждым из них в произвольном порядке. Других людей нет (для упрощения)

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

Как бы вы справились с этой ситуацией, чтобы избежать "адской версии"? Один из способов, который я могу придумать, - это использовать символические ссылки / жесткие ссылки, но они не идеальны - если вы удалите одно центральное хранилище, все пойдет в ад. И жесткие ссылки не будут работать в системе с двойной загрузкой (хотя символические ссылки будут). Похоже, мне нужно что-то вроде расширенного git-репозитория, где код проекта хранится в одном локальном репозитории, но синхронизируется с несколькими внешними репозиториями. Но я не уверен, как это сделать или возможно ли это сделать с помощью git.

Итак, что вы думаете?

Answer 1

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

Тогда другие проекты, которым нужна библиотека, могут получить нужные файлы из проекта библиотеки.

Answer 2

Мне не совсем понятно, что вы хотите, но, возможно, подмодули git могут помочь: http://git -scm.com / docs / git-submodule

Answer 3

С точки зрения конфигурации (общие), решение состоит в том, чтобы иметь несколько соединительных линий (ветвей):

• Release
• Интеграция
• Разработка

Release
Этот ствол / ветвь содержит программное обеспечение, которое прошло проверку качества и может быть передано клиенту. После выпуска все файлы помечаются как «только для чтения». Им присваивается метка для идентификации файлов с номером выпуска.

Периодически или по требованию гуру тестирования берут последнюю версию (подсказку) из магистрали интеграции и подчиняются изнурительным качественным тестам. Таким образом интеграционная версия повышается до версии выпуска.

Интеграция
Этот транк содержит последний рабочий код. Он содержит исправления ошибок и новые функции. Файлы должны быть помечены после каждого исправления ошибки или новой функции.

Код перемещается в ветку интеграции после того, как ошибка прошла качественное тестирование или новая функция полностью разработана (и протестирована). Хорошая идея - пометить версию интеграции временной меткой перед интеграцией кода разработчика.

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

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

---

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

Я изучал GIT и SourceSafe, пытаясь выяснить, как реализовать эту схему. Схема легко реализуется в более крупных приложениях для управления конфигурацией, таких как PVCS и ClearCase. Похоже, для GIT необходимы дублированные репозитории (один репозиторий для каждой магистрали). SourceSafe четко заявляет, что он допускает только одну метку на версию, поэтому файлы, которые не были изменены, будут терять информацию метки.

Answer 4

В Subversion вы можете использовать внешние (это не GIT, я знаю, но эти советы могут все же помочь). Вот как это работает:

• Разделить код приложения (\ MYAPP) и общий код (\ COMMON)
• Удалить все дубликаты из приложений; они должны использовать только общий код
• Введите общий код в приложениях, добавив \ COMMON в качестве внешнего в \ MYAPP

Возможно, у вас также будут версии вашего приложения. Также внесите версии в общий код. Таким образом, ваше приложение будет иметь следующие папки в хранилище:

• \ MYAPP \ БАГАЖНИКА
• \ MYAPP \ V1
• \ MYAPP \ V2

Аналогичным образом добавьте версии к общему коду, используя номера версий, например:

• \ COMMON \ БАГАЖНИКА
• \ COMMON \ V1
• \ COMMON \ V2

Или используя даты, например:

• \ COMMON \ БАГАЖНИКА
• \ COMMON \ 2010JAN01
• \ COMMON \ 2010MAR28

Внешний вид \ MYAPP \ TRUNK должен указывать на \ COMMON \ TRUNK, это очевидно.

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

например. внешние элементы \ MYAPP \ V1 могут указывать на \ COMMON \ 2010JAN01.

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

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