Способ решения аналогичной проблемы - это то, что вы описываете в обновлении 2, но там, где вы предлагаете «резервные копии», мы используем клонов, и они являются неотъемлемой частью нашего рабочего процесса.
Мое решение.
Мы используем комбинацию клонов и именованных ветвей, чтобы мы могли контролировать, когда библиотеки для конкретного приложения (решение в вашем примере) обновляются.
Что мы делаем, так это имеем основной репозиторий для каждой из наших библиотек, который содержит основную ветвь этой библиотеки. Когда мы создаем новое приложение, мы клонируем все соответствующие библиотеки (мы используем одно ртутное хранилище для каждой библиотеки, где библиотека может содержать библиотеку и ее тестовое приложение) в каталогах рядом с новым приложением и ссылаемся на библиотеки в этом приложении.
Любые коммиты в библиотеки для этого приложения фиксируются в ветке, названной в соответствии с приложением. Когда приложение завершено, мы просматриваем изменения в библиотеке и затем объединяем соответствующие изменения обратно в основную линию, создавая новую основную линию. Это также имеет то преимущество, что в будущем вы можете легко определить, какое приложение вызвало конкретное изменение в библиотеке, посмотрев, в какую ветку было внесено это изменение.
Всякий раз, когда мы прикасаемся к приложению, мы можем выбрать, продолжать ли использовать старые библиотеки или обновиться до более поздней основной версии (или даже другой версии разработки проектов) библиотеки. Изменения библиотеки не распространяются на каждое приложение, которое их использует (некоторые могут быть устаревшими приложениями, которые не были затронуты в течение многих лет и прекрасно работают с библиотекой, с которой они поставлялись), они включаются приложениями, которым требуется новая объекты в данной версии библиотеки.
Почему я так делаю?
Здесь я пытаюсь избежать проблемы, с которой я постоянно сталкивался в предыдущей компании.
Я бы заставил мое приложение работать с данной библиотекой. Кто-то другой изменил бы библиотеку для своего приложения, чтобы она делала то, что им нужно, и в следующий раз, когда я отправлюсь редактировать свой проект, она не будет компилироваться. Затем мне пришлось бы потратить время на исправление своего проекта, чтобы вести себя так, как этого хочет сейчас библиотека, или потратить время на то, чтобы отменить неуместные изменения, внесенные в библиотеку (что затем привело бы к каскадному обращению к другому разработчику).
Благодаря локальным проектным клонам каждое приложение может выбирать, когда оно обновляется до более поздней версии библиотеки, и с точки зрения случайного управления мы можем просматривать изменения в библиотеках в соответствии с требованиями приложения, прежде чем они будут объединены с основной линией.
Это рабочий процесс, который никогда не был бы возможен с традиционными VCS, такими как SourceSafe, но прекрасно работает с DVCS, такими как Hg.
Конкретные решения этих неуловимых целей.
Чтобы попытаться ответить на ваши неуловимые цели
0,3. Каждый репозиторий содержит весь исходный код, включая библиотечные проекты
Путем клонирования библиотек в каталоги, близкие к вашему приложению, вы получаете набор репозиториев, которые могут управляться вместе и, возможно, в конечном итоге превратятся в суб-репо супер-репо «приложения».
0,4. Все максимально автоматизировано, чтобы минимизировать риск ошибок
Я делаю это с кучей пакетных файлов, которые я храню в каталоге своего приложения.
Например, данное приложение "_projects.bat" может содержать:
@echo off
@shift
set APPDIR=%CD%
cd ..\Library1
%0 %1 %2 %3 %4 %5 %6 %7 %8 %9
cd ..\Library2
%0 %1 %2 %3 %4 %5 %6 %7 %8 %9
cd ..\Library3
%0 %1 %2 %3 %4 %5 %6 %7 %8 %9
cd %APPDIR%
%0 %1 %2 %3 %4 %5 %6 %7 %8 %9
pause
Затем у меня есть пакетные файлы для выполнения полезных функций синхронизации, таких как проверка, какие файлы будут извлечены с помощью "__incoming.bat:
@echo off
call _projects hg incoming
и проверьте, что будет выдавлено с помощью __outgoing.bat:
@echo off
call _projects hg outgoing
Или фактически выполнить эти операции с "__push.bat":
@echo off
call _projects hg push
и "__pull.bat":
@echo off
call _projects hg pull
пока "__update.bat" обновляет все до последней версии (в той же ветке вам все равно придется явно обновляться вне текущей ветки):
@echo off
call _projects hg update
Одним из моих любимых файлов является "__ids.bat", который показывает, какие наборы изменений (и разветвленные) в настоящее время используются и, что важно, есть ли у них невыполненные изменения:
@echo off
call _projects hg id
Всякий раз, когда я начинаю работу над обновлением приложения, я проверяю, есть ли обновленные библиотеки, выпадаю все, что уместно, обновляюсь до нужных мне версий и затем продолжаю разработку.
Обратите внимание на то, что подчеркивания в именах файлов просто помещают их в верхнюю часть списков каталогов, чтобы их было легче найти. * 8' )
Будущие варианты.
В конце концов, я бы хотел полностью автоматизировать этот рабочий процесс с помощью суб-репо (чтобы состояние всего приложения и всех его библиотек записывалось в одном наборе изменений приложения), но пока оно становится довольно стабильным в Mercurial, интеграция с TortoiseHG не кажется приоритетом. Я не мог заставить инструмент THG commit делать что-нибудь полезное в прошлый раз, когда я его пробовал (около 0.8.3). Я действительно должен повторить тестирование с 0.9.3, но я не могу вспомнить какие-либо заметки о суб-репо в журналах изменений, поэтому оно того не стоит, если люди не скажут мне, что поддержка суб-репо THG была тихо добавлена.
Как таковые, пакетные файлы работают довольно хорошо. Следующая вещь в моем списке задач - это __clone.bat, который должен значительно облегчить клонирование приложения и всех его библиотек, но у меня не было времени, чтобы заставить это работать.
Если кому-то захочется попробовать, я бы хотел увидеть ответ в этой теме. * 8' )
Берегите себя, надеюсь, это поможет,
Mark ..........