Метки контроля SVN с внешним обликом на ответвлениях разработки
Я предлагаю использовать SVN, потому что:
- Управление исходным кодом дает Вам превосходную историю. Вы видите, где, какие изменения были внесены, таким образом обеспечив отличный способ видеть то, что изменяется со временем (еще лучше, если Вы заполняете отправлять сводку каждый раз)
- разработчику, она обеспечивает превосходную нейтрализацию, если что-то идет ужасно неправильно. Можно вернуться изменения в файле назад к любой точке в ее истории, таким образом, можно испытать ту модификацию, Вы хотели сделать, и если это не работает, прокручивает его назад легко.
- Это обеспечивает центральный репозиторий, которого намного легче создать резервную копию, чем обтекание к компьютерам различных разработчиков.
- Это позволяет Вам переходить проект прочь в другом направлении - полезный для специализаций и настроек.
- Это позволяет больше чем одному разработчику сотрудничать на том же проекте и том же источнике, позволяя Вам объединиться и иначе управлять изменениями в одной центральной копии.
я предлагаю НЕ использование, VSS - видят эту страницу по причинам: http://www.highprogrammer.com/alan/windev/sourcesafe.html по большему количеству причин.
4 ответа
Я бы использовал две стратегии для решения этой проблемы
- автоматизацию тегов. Создайте сценарий оболочки, который изменяет все svn: externals на фиксированный тег ревизии / выпуска перед созданием тега в проекте. У
- есть сценарий, который проверяет существующие теги на согласованность. На самом деле возможно реконструировать состояние во время тегирования, даже если вы подключили внешнее устройство к магистрали: поскольку вы знаете дату и время создания тега, вы также можете узнать, какая ревизия магистрали была активна в этот момент, и либо изменить внешнее, чтобы указать на конкретную ревизию ствола или на выпуск, который был текущим на момент создания тега.
Кроме того, вы также можете придумать ловушку перед фиксацией, которая проверяет, является ли тег создается, и все ли внешние элементы указывают на фиксированные версии,
Звучит банально, но, безусловно, лучше всего не ссылаться на ветки разработки библиотек. Вы бы не сделали этого, если бы это была сторонняя библиотека, и делать это с вашими собственными библиотеками тоже не рекомендуется.
Может показаться, что это потребует больше работы, но если вы обнаружите ошибку в ссылочную библиотеку, исправьте ее, пометьте новый выпуск и укажите этот новый тег в своем проекте.
Если вам действительно нужно ссылаться на ветки разработки библиотек, вы можете использовать скрипт ловушки предварительной фиксации, который определяет, когда вы делаете тег и гарантирует, что все упомянутые внешние объекты также являются помеченными версиями: тогда сценарий может завалить фиксацию, если это не так. Впрочем, каждый раз, когда вы делаете коммит, это довольно неприятно.
Мы также хотим для принудительного применения политики замораживания внешних файлов, которые копируются в теги, но еще не полностью реализовали ее на сервере.
Идея состоит в том, чтобы обработчик предварительной фиксации использовал команду svnlook с транзакцией номер для проверки наличия каких-либо "тегов /" назначения в копии. В случае попадания необходимо проверить свойства и найти любые svn: externals . Возможно, другие свойства, позволяющие переопределить политику.
Очевидный вопрос - это нагрузка на сервер и какой язык использовать для этой ловушки. Обычно SVN поставляется с лучшими привязками Python Ctypes, к сожалению, в прошлый раз, когда я проверял, он недоступен для Windows (не компилируется, как для этой цели). Но модуля pysvn может быть достаточно для этого. Помимо этого языка, сценарии bash могут работать, но будут беспорядочными и не такими переносимыми. Или чистый C ...
, не обращаясь с вашими внутренними библиотеками так же, как с внешними? Если вы используете Apache Ivy (соответственно Maven), было бы довольно легко опубликовать ваши библиотеки в центральном репозитории (с номером версии 1.0 или SNAPSHOT_20091005) и просто импортировать их, используя стандартный механизм Ivy (соответственно Maven).
Таким образом, вы устраните все проблемы с внешним видом SVN. Конечно, каждый проект должен будет использовать теги перед созданием релиза, но это «релиз 101».