Хранение всех проектов Visual Studio в синхронизации с библиотекой

Я не уверен, что я понимаю целью вашей «библиотеки»?

Почему два решения не относятся к тому же проекту, а не копию?

Если цель состоит в том, чтобы иметь возможность работать на разных ветвях «библиотеки», то то, что вы описываете, это такая вещь, обработанная программным обеспечением управления исходным кодом, как SVN.

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

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

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

Я бы порекомендовал переместить библиотечные проекты в библиотеку. Ваша диаграмма показывает код библиотеки прикладных решений и нажимает его в библиотеку, а затем всасывает встроенные файлы библиотеки обратно в проекты - двунаправленная копия, EEK! Просто поместите библиотечные проекты в библиотеку и постройте библиотеку, а затем ссылайтесь на то, что библиотека из ваших проектов - унидиеная копия. Вы можете подумать, что это будет означать, что вы должны построить два решения (библиотека, а затем приложение), но вы можете добавить / удалить библиотечные проекты в вашем приложении, когда вы хотите, поэтому этот макет не требует двухступенчатого процесса сборки. Но логическое различие между библиотекой и приложением намного чище.

Извините, я не прочитал весь текст на этой странице. Но! Короткий ответ: Visual Studio делает всю необходимую автоматизацию .

У нас похожая структура. Solution1, Solution2 и общая библиотека с несколькими проектами в ней. Структура папок в SVN выглядит следующим образом:

\myRepository
            \Solution1
            \Solution2
            \CommonLibrary\
                          \Project1
                          \Project2
                          \Project3

Как видно здесь нет копирования. Оба решения просто содержат ссылку на ..\CommonLibrary\ProjectX.

После выполнения команды SVN-Update для репозитория Visual Studio просит меня 'ProjectX был изменен. Хотите перезагрузить его? Я нажимаю 'yes' и продолжаю кодирование.

PS: также посмотрите на это программное обеспечение http://svnnotifier.tigris.org/ Оно может обновлять любое количество локальных копий репозитория автоматически (по таймеру) или щелчком мыши.

Способ решения аналогичной проблемы - это то, что вы описали в обновлении 2, но там, где вы предлагаете «резервные копии», мы используем клоны, и они являются неотъемлемой частью нашего рабочего процесса.

Мое решение.

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

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

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

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

Почему я делаю это именно так?

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

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

В случае клонов локальных проектов каждое приложение может выбирать, когда оно обновляется до более поздней версии библиотеки, и с точки зрения случайного управления мы можем просмотреть изменения в библиотеках из-за требований приложения, прежде чем они будут снова объединены в основную ветку.

Это рабочий процесс, который никогда не был бы возможен с традиционной VCS, такой как SourceSafe, но прекрасно работает с DVCS, например Hg.

Конкретные решения этих труднодостижимых целей.

Чтобы попытаться ответить на ваши неуловимые цели

.3.Каждый репозиторий содержит весь исходный код, включая проекты библиотек

. Клонируя библиотеки в каталоги, близкие к вашему приложению, вы получаете набор репозиториев, которыми можно управлять вместе, и, возможно, в конечном итоге они будут хорошо преобразованы в суб-репозитории «приложения» супер-репо.

.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 делать что-нибудь полезное в последний раз, когда я его пробовал (около 0.8.3). Мне действительно нужно провести повторное тестирование с 0.9.3, но я не помню, чтобы видел какие-либо заметки о суб-репозиториях в журналах изменений, так что это не стоит того, если только люди не сообщают мне, что поддержка суб-репо THG была добавлена ​​молча.

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

Если кому-то захочется попробовать, я хотел бы увидеть ответ в этой ветке. * 8 ')

Осторожно, надеюсь, это поможет,

Марк ..........