Иногда нужно быстро откатиться к стабильному коду в репозитории Subversion не теряя проделанную работу в рабочей копии. Предложенный подход состоит в сохранении всех изменений рабочей копии в архиве с помощью UNIX-команд. Для этого необходим либо полноценный UNIX либо Cygwin + утилита архивации.
Сокращения
РК --- локальная рабочая копия репозитория Subversion
Реализация подхода
- Перейти в каталог РК, который нужно откатить до зафиксированного состояния.
- Выполнить команду
svn st | grep -v "^D" | awk '{print $2}' | xargs rar a ~/tmp/modified.rarгде~/tmp/modified.rar --- полный путь к архиву с сохраненными изменениями в РК. - Откатить каталог РК до зафиксированного состояния.
svn -R revert .
svn st | awk '{print $2}' | xargs rm
Что бы вернуть РК в состояние до отката:
- Перейти в каталог РК, которую откатывали на зафиксированное состояние.
- Выполнить команду:
rar x ~/tmp/modified.rar
Команды для лаконичности поместить в скрипты либо сделать доступными по горячим клавишам.
Недостатки
При возврате РК в состояние до отката остаються неудаленными файлы, которые были удалены (svn rm) в изначальной изменненой РК.
Преимущества
Скорость работы выше чем у команды svn export, поскольку архивируются только измененные файлы.
Loading ...
августа 29, 2008 в 7:47 pm
Это какой объем кода должен быть для того чтобы отказаться от GUI клиентов и банального копирования/архивирования текущего кода?
августа 30, 2008 в 2:24 am
или я чегото непонял или зачем в Subversion придуманы бранчи? как раз, для того чтобы перейти к работе в определенной ветке.
Сергей, откройте для себя Сабвершн. архивирование кода это было актуально может в 90х
августа 30, 2008 в 10:22 am
2 Rayan
подход можно использовать в типичной ситуации, когда нужно быстро проверить какие реакции были у стабильного кода, а изменения в коде РК недоделаны, т.е. фиксировать их смысла никакого нет, но если делать простой откат, то изменения просто потеряются. Такой подход существенно быстрее по времени, чем создание ветки по РК, откат на стабильный код, переключение на созданную ветку, доработка кода в ветке, слияние кода ветки в исходную ветку --- масса ненужных операций просто ради сохранения недоделки.
2 Сергей
Эти операции можно встроить в GUI клиент, ведь сам GUI клиент использует те же вызовы. От подхода "копирование/архивирование" отказались, поскольку он порождает хаос при управлении конфигурациями. Если имелось ввиду копирование всей РК, то это неэффективно и может вызвать ошибки целостности РК при восстановлении на нестабильное состояние. Если имелось ввиду архивирование выхода svn export, то этот случай был рассмотрен выше.
августа 30, 2008 в 11:24 am
Наконец-то что-то новенькое на цкдеве
Тема управления версия очень актуальна, в связи с чем предложение. Дима, может сделаешь цикл мини-статей об использовании subversion'а (о тех же бранчах, например)?
августа 30, 2008 в 11:40 am
по возможности постараюсь, время Виталик, время
сентября 1, 2008 в 12:02 am
да ну, бранчи и только бранчи. откатываться никуда не надо, если стабильный код фиксируется отдельным тегом. Он просто лежит в отдельной папке рядом с основной веткой. Как часто создавать теги - вопрос к процессу. Разумнее всего раз в сутки, во время ночных билдов.
"There are some standard, recommended ways to organize a repository. Most people create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies. If a repository holds only one project, then often people create these top-level directories:
/trunk
/branches
/tags
сентября 3, 2008 в 5:23 pm
сентября 4, 2008 в 11:21 am
osa, я не увидел простоты в предложении плодить ветки с временем жизни 5-7 минут, а потом их сливать и удалять.
сентября 22, 2008 в 1:54 pm
Дима, ветки тегов и бранчей обычно не удаляют.
Бранч создается моментом, командой svn cp, причем реального копирования в репозитории не происходит. SVN хитро такими вещами управляет.
А при необходимости одновременно править несколько веток, я делаю чекаут нескольких рабочих копий. У меня есть отдельная копия проекта для ревью. Отдельная для мерджинга. Отдельная для транка.
У меня недавно с SVN была другая интересная задача - совместить два проекта и при этом не потерять информацию о версиях. (банальное копирование - теряет версии, а команда svn cp похожде не умеет делать это рекурсивно)
сентября 22, 2008 в 7:58 pm
>>ветки тегов и бранчей обычно не удаляют
кто как, я под задачу создаю отдельную ветку, после слияния в ствол ее удаляю, это канонический вариант использования.
>> совместить два проекта
не туда смотрел, svnadmin и утилиты обслуживания репозитория, на клиенте эти вещи не советую делать.
сентября 22, 2008 в 10:15 pm
Мы делаем бранч под релиз. Задачи мы коммитим в транк, и круизконтроль все это дело собирает прогоняет кучу тестов тестер руками тестирует. Так быстрее фидбэк ну и гемора с мерджингом меньше. Получается мерджинг в среднем раз в итерацию.
>>>> совместить два проекта
>>не туда смотрел, svnadmin и утилиты обслуживания >>репозитория, на клиенте эти вещи не советую делать.
Я где-то сказал репозитория?
сентября 25, 2008 в 2:42 pm
>>Я где-то сказал репозитория?
"совместить два проекта и при этом не потерять информацию о версиях"
тогда не представляю что ты хотел все-таки получить в результате совмещения.