Mercurial: поддержка Visual Studio 2005 и 2008 филиалов - PullRequest
3 голосов
/ 04 декабря 2009

Я пытаюсь разработать рабочий процесс, который позволяет нам поддерживать отдельные версии библиотек Visual Studio 2005 и 2008, в то же время следя за тем, чтобы изменения в одной ветви всегда реплицировались в другой ветви.

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

Я знаю, что мы могли бы сохранить изменения между проектом VS2005 и VS2008 в очереди исправлений, но я единственный в моей команде, которому удобно использовать командную строку, мои коллеги предпочитают делать все, хотя Tortoise HG .

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

Прочитав эту статью , я попытался выполнить резервное копирование набора изменений 'upgrade', но результирующий набор изменений backout всегда заканчивается как новый совет ветки VS2008, плюс я не могу затем объединить изменения обратно, так как результирующее слияние заканчивается в ветке VS2008, даже если я пытаюсь явно закрыть ветку при фиксации.

Я пытался пойти на это несколькими способами, но я всегда получаю новую ветку VS2008 и не могу объединить изменения обратно с веткой по умолчанию. Таким образом, я начинаю осознавать, что упустил здесь нечто очевидное.

Итак, в конечном итоге, что другие люди считают наилучшей практикой, когда пытаются поддерживать две версии библиотеки, где единственное различие между ними - номера версий Visual Studio, встроенные в файлы проекта и решения?

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


Дальнейшее редактирование, с решением.

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

Во-первых, я обновил набор изменений, в котором проект был преобразован из VS2005 в VS2008. Я отказался от этой ревизии, создал патч возврата и удалил набор изменений (поскольку он был в ветке по умолчанию). Затем я применил патч возврата к ревизии преобразования (используя: hg patch --no-commit patch), а затем применил патч с новым именем ветки "VS2005". Затем я объединил кончик (неназванной) ветки VS2005.

Следующим шагом было обновление до старой вершины ветки VS2008 (без имени), внесение несущественного изменения и принятие его в качестве новой ветки VS2008. Затем я объединил изменения из подсказки VS2005, но когда я это сделал, не позволил внести изменения в файлы csproj. Затем я вернул эти файлы после коммита.

Наконец, я обновился до подсказки VS2005 и объединил в подсказку VS2008.

Это привело к двум подсказкам с одинаковым кодом, за исключением различий, связанных с преобразованием VS2005 в VS2008.

Новый рабочий процесс:

  • Работайте в ветке VS2005 или VS2008, как требуется.
  • Как только обновления будут выполнены в одной ветви, обновитесь в другой ветви, объедините изменения из измененной ветви и зафиксируйте в своей собственной ветви. Затем вернитесь к предпочитаемой ветке.
  • Если обновления происходят в обеих ветвях одновременно, делайте обе ветки по отдельности, т.е. обновите подсказку VS2005 и объедините в подсказку VS2008, затем обновите подсказку VS2008 и объедините в предыдущую (до объединения) подсказку VS2005.

Ответы [ 5 ]

2 голосов
/ 04 декабря 2009

Вместо решения проблемы вы можете попытаться ее устранить: попробуйте premake .

Premake - это система перед сборкой (как следует из названия, она предназначена для запуска pre-make или pre-MSBuild, если хотите). Вы описываете свой проект один раз в декларативном внутреннем DSL, построенном на основе языка сценариев Lua *1008*, и premake может автоматически создавать решения и проекты для VS2008, 2005, 2003 и 2002, MonoDevelop, SharpDevelop , Code :: Blocks, CodeLite или GNU Makefile для Unix, Cygwin или MinGW. В настоящее время он поддерживает создание проектов C ++, C и C #, включая кросс-компиляцию для 32/64 бит, OSX Universal Binaries, PlayStation 3 и XBox 360.

Язык конфигурации очень чистый и декларативный . Однако, будучи встроенным как внутренний DSL поверх Lua, у вас также есть полная поддержка очень мощного, красивого, выразительного (и, что наиболее важно, Turing-complete) языка сценариев в ваших руках. И структура, и терминология языка конфигурации напрямую основаны на Visual Studio: в нем говорится о решениях, проектах , конфигурации и платформах .

Сам инструмент premake распространяется как один .exe , который включает в себя интерпретатор Lua, стандартную библиотеку Lua и, конечно, сам скрипт premake. Он не имеет абсолютно никаких внешних зависимостей, не записывает файл конфигурации и не записывает или даже просто читает реестр.

Все, что вам нужно сделать, это перевести решение VS2008 в premake один раз вручную.

1 голос
/ 04 декабря 2009

Книга Mercurial: полное руководство содержит целую главу об использовании очередей исправлений Mercurial для поддержки обратных портов для старых ядер Linux.Я думаю, что расширение mq может вам помочь.

1 голос
/ 04 декабря 2009

Мы используем отдельные файлы решения и проекта. Мы копируем файлы .sln и .csproj / .vcproj / .vbproj и редактируем их в блокноте, чтобы использовать новые файлы. Вам все равно нужно помнить, что при добавлении классов вам нужно добавить файл в другое решение, но в противном случае вам не нужно будет копировать исправления.

0 голосов
/ 15 января 2010

Кажется немного странным отвечать на мой собственный вопрос, но без этого я не могу указать StackOverflow, что на этот вопрос принят приемлемый ответ.

Полную информацию смотрите в моем вопросе - после горизонтального правила.

Я должен добавить мою благодарность за ответы всех остальных. Я все еще могу найти применение premake, и отдельные файлы проекта / решения могут работать в других ситуациях. Однажды я, несомненно, сам найду применение для Mercurial Queues, но я сомневаюсь, что когда-нибудь заставлю их использовать остальную часть моей команды разработчиков. Мне никогда не было удобно с жесткими ссылками на Windows, поэтому я, вероятно, никогда не буду пробовать это, но это хорошо, чтобы напомнить об их наличии.

Берегите себя и еще раз спасибо всем, кто нашел время ответить.

0 голосов
/ 05 декабря 2009

Возможно, вам не следует поддерживать две разные ветви, а только одну, содержащую исходный код и файлы проекта Visual Studio 2005. Вторая ветвь должна содержать только файлы проекта Visual Studio 2008, а не исходный код. Для компиляции версии Visual Studio 2008 создайте жесткие ссылки на локальном диске для всех исходных файлов, чтобы они отображались в обоих деревьях папок (поместите создание жесткой ссылки в пакетный файл вместе с командами для получения последних обновлений из хранилища ). Для этого подхода вам понадобится файловая система NTFS и соответствующий инструмент командной строки «ln», например this .

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

Редактировать: и да, я попробовал это сам, это работает. У нас очень похожий сценарий: приложение C ++ для компиляции с Visual Studio 2008 и более старый компилятор Borland.

...