Как использовать Subversion для некомпилированного языка?

Question

Я хочу использовать Subversion с системой разработки на основе сценариев, и мне было интересно, что делать иначе, чем в моей обычной ситуации (C # /. NET).

Нормальный ежедневный цикл обновления / фиксации будет работать нормально, так же как и отслеживание изменений и сравнение ревизий. Я хотел бы получить несколько советов по обработке развертывания.

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

Изменения в сценарии не обязательно включены в следующий выпуск - они могут быть предназначены для выпуска после этого или после него.

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

Обновление

Насколько я могу судить, ни теги, ни списки изменений не помогут.

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

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

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

Обновление 2

Два примера, показывающие, как я могу справиться с этой ситуацией с помощью других инструментов. Обратите внимание, что я вообще не пытаюсь продвигать эти инструменты, так как я хочу использовать Subversion, я просто пытаюсь понять, как это сделать.

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

Аналогично, с StarTeam я могу применить метку к ревизии файла и проверить только файлы с этой меткой.

Answer 1

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

На самом деле это не сильно отличается от рабочего процесса использования Subversion со скомпилированным языком или даже для каких-либо других целей.

См. Раздел Общие ветвящиеся шаблоны книги Subversion для получения дополнительной информации. В частности, раздел «Особые ветви» звучит наиболее подходящим для вашей ситуации.

Answer 2

Одним из решений будет запуск новой ветви с использованием svn mkdir (вместо svn copy), а затем выборочное копирование файлов, необходимых из основной ветви, путем svn copy

Answer 3

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

Это именно то, для чего предназначены метки .

Answer 4

Я вижу проблему - которая не имеет ничего общего с SVN. Вы хотите хранить некоторые файлы в ветке релиза, но не другие. Так что либо разветвите весь каталог выпуска, а затем удалите файлы, которые вы не хотите показывать там; или создайте новый пустой каталог и скопируйте только те файлы, которые вам нужны.

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

Answer 5

Я считаю, что с SVN 1.6 вы можете иметь внешние ссылки на отдельные файлы. Таким образом, если вы хотите, вы можете создать пустую древовидную структуру и определить на ней набор внешних элементов, которые добавят нужные файлы в структуру. Это дало бы вам вид «живого» обзора ветки.

Возможно, вы могли бы ссылаться на версии файлов непосредственно из ствола - или вы могли бы наложить свой подход и использовать ветку релиза для объединения определенных ревизий, а затем сослаться на эту ветку релиза во внешних элементах вашего «живого просмотра». Таким образом, вы выпускаете функции путем слияния ревизий - сохраняя нормальный контроль ревизий и историю слияний, а затем svn-обновление на сервере приводит эти файлы в живую структуру.

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

Небольшая информация о внешних файлах доступна в заметках о выпуске svn 1.6

Answer 6

Похоже, вы ищете метаданные о конкретных сценариях. Таким образом, один из вариантов - хранить ваши скрипты в виде отдельных файлов и использовать svn properties . Свойства Svn позволяют хранить пары ключ-значение, связанные с файлом.

Например, чтобы отразить пример «метки», вы можете создать свойство для каждого файла, который вы решите включить в конкретный выпуск. В этом случае создайте свойство «Сентябрь 2009» со значением «true».

При создании пакета развертывания вы можете выбрать только файлы со свойством «Сентябрь 2009».

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