Вопрос

Моя команда скоро перейдет с Visual SourceSafe на Subversion, одновременно разрабатывая/поддерживая устаревший проект на Visual Basic 6.0, поэтому у меня есть пара вопросов:

  • Какой инструмент лучше всего подходит для интеграции Subversion IDE в Visual Studio 6?(или оно того не стоит...)
  • Существуют ли рекомендации по использованию Subversion с Visual Basic 6.0?(типы файлов, которые следует игнорировать и т. д.)
Это было полезно?

Решение

Я согласен, что Tortoise SVN в проводнике Windows будет лучшим способом использования SVN с VB6.

Самым большим изменением, которое вы обнаружите при переходе на SVN, является идея «Извлечь» и «Вернуть» — это не совсем то же самое, что «Обновить» и «Зафиксировать»...таким образом, любая интеграция IDE с VB6 ограничена, поскольку VB6 поддерживает MSSCCI, механизм извлечения/возврата.Я когда-то использовал TamTam SVN (http://www.daveswebsite.com/software/tamtamsvn/index.shtml) с Visual Studio 2003, но остановился, так как счел это ограничивающим.Слияние/ветвление/обвинение и т. д.- это очень мощные функции, предоставляемые Tortoise SVN, которых не было в TamTam.У Тигриса тоже есть http://svnvb6.tigris.org/, но я не пробовал.

Опять же, хотя вы вполне можете получить IDE для работы с VB6, я бы не рекомендовал ее, поскольку самая сильная сторона перехода на SVN — это нарушение философии Source Safe по возврату/извлечению.

Другие советы

Поскольку Subversion использует цикл обновления/редактирования/фиксации (а не возврата/извлечения), вам необходимо быть особенно осторожным с двоичными файлами.Большинство форм в VB6 состоят из двух файлов:MyForm.frm и MyForm.frx.Файлы *.frx являются двоичными и поэтому не могут быть объединены.

Учитывая это, я бы настроил Subversion так, чтобы она требовала «блокировки» файлов .frx.Это означает, что одновременно извлечь файл может только один человек.Поступив так, вы обеспечите, чтобы только один разработчик мог изменять эти файлы одновременно, и всегда будет ясно, кто этот человек в данный момент.Если вы этого не сделаете, вы настроите себя на серьезные головные боли.

Типы файлов, которые следует игнорировать:

*.vbw
Файл рабочей области, который автоматически создается при закрытии проекта и содержит сведения об открытых файлах и т. д.

MSSCCPRJ.SCC
Файл состояния системы управления версиями, созданный средой разработки VB6 (если вы используете решение управления SVN в проводнике Windows, вам следует отключить плагин системы управления версиями в VB6, и он не будет создан).

*.log
Это файлы, создаваемые, если что-то идет не так при загрузке графического интерфейса формы.Файл находится там же, где и файл формы с именем, равным файлу формы.
Пример: MyForm.frm генерирует MyForm.log.

Конечно, вам следует делать это только в том случае, если у вас нет файлов журналов, которые вам нужны в системе контроля версий...

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

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

Я думаю, что существуют инструменты, которые выполняют миграцию с SourceSafe на SVN.(Да, быстрый поиск в Google подтвердил это.) Таким образом, вы не потеряете историю изменений.

Я бы предположил, что не стоит беспокоиться об интеграции и просто использовать Tortoise SVN в проводнике Windows.

Что касается типов файлов, которые следует игнорировать, протестируйте их, проверьте, создайте и посмотрите, не изменились ли какие-либо файлы (для современной Visual Studio я склонен игнорировать файлы .suo).

Что касается серверной части, VisualSVN Server — это очень простое решение, мы запускаем его в виртуальной среде vmware, и оно работает.

Если вы работаете с командной строкой, то мне очень нравится интерфейс командной строки для svn, мне легче выполнять определенные действия, чем в черепахе, например, статус папки.Но если вы поклонник исследователей, черепаха более чем достаточна, поскольку она происходит из безопасного мира.

Основные вещи, которые следует игнорировать:

  • Воспроизводимые артефакты (dll, pdb, exe)
  • Настройки, специфичные для среды (т. е.файл настроек для vs, файл csproj.user, файлы .suo)

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

При копании в устаревшем коде действительно полезно иметь всю историю и вину.SVN намного лучше, чем VSS, но при переключении вы потеряете историю.

Если вы собираетесь постоянно заниматься разработкой VB6, то, возможно, стоит переключиться на SVN, но если вы собираетесь делать так много в будущем, стоит ли пересматривать проект?

У меня аналогичная проблема, только устаревшие проекты находятся в Delphi.Если бы они были в VB6, я бы подумал об «обновлении» их до VB.Net просто для удобства обслуживания.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top