Comments 34
спасибо конечно за скрипт
но не могли бы вы конкретней описать опцию, дающий такой результат.
а то не сразу понятно что за результат?
svn diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]]
?
тк не поставлина задача сложно что-то сказать
но мне кажется что решение должно быть и по проще =) (с помощь awk и тп)
но не могли бы вы конкретней описать опцию, дающий такой результат.
а то не сразу понятно что за результат?
svn diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]]
?
тк не поставлина задача сложно что-то сказать
но мне кажется что решение должно быть и по проще =) (с помощь awk и тп)
Задача описана в статье «Умный экспорт из SVN при помощи TortoiseSVN», ссылка на которую дана в начале.
Если коротко, то я хочу экспортнуть из репозитория файлы, которые были изменены в промежутке между начальной и конечной ревизиями. Чтобы потом их залить уже на живой проект. Простым копированием.
svn diff же даёт вывод утилиты diff, применённой к изменившемся файлам.
Что же касается сложности скрипта, то я его сделал за 2 часа не зная ни bash, ни awk, ни sed. И теперь пользуюсь им каждый день.
Я уверен, что это можно было бы сделать проще, но у меня вышло так. И на этом остановился, потому как скрипт стал делать то, что я хотел от него получить.
Если коротко, то я хочу экспортнуть из репозитория файлы, которые были изменены в промежутке между начальной и конечной ревизиями. Чтобы потом их залить уже на живой проект. Простым копированием.
svn diff же даёт вывод утилиты diff, применённой к изменившемся файлам.
Что же касается сложности скрипта, то я его сделал за 2 часа не зная ни bash, ни awk, ни sed. И теперь пользуюсь им каждый день.
Я уверен, что это можно было бы сделать проще, но у меня вышло так. И на этом остановился, потому как скрипт стал делать то, что я хотел от него получить.
Держу отдельную рабочую копию для заливки на сервер.
Для заливки использую rsync -avzC -e ssh…
Отправляются только измененные файлы, файлы архивируются и упаковываются в блоки большего размера. Все передается через защищенный туннель.
Рекомендую!
Для заливки использую rsync -avzC -e ssh…
Отправляются только измененные файлы, файлы архивируются и упаковываются в блоки большего размера. Все передается через защищенный туннель.
Рекомендую!
честно, не знаю что такое «умный экспорт», но в линуксе есть хороший редактор, называется Geany, и у него есть опция показывающая (не в лучшем виде конечно, но все изменения четки и ясны) изменения между текущей и предидущей ревизией… может быть это то чего Вам не хватало?
Тут штука вот в чём. Изменения между текущей и предыдущей ревизией и без специальных редакторов посмотреть можно.
Например, просто консольной командой svn diff --summarize
А скрипт написан для повторения функционала TortoiseSVN, а именно получения изменившейся части дерева проекта с учётом вложенности каталогов.
Вручную же собирать это дело, глядя на вывод svn diff --summarize надоедает уже на третий раз.
Например, просто консольной командой svn diff --summarize
А скрипт написан для повторения функционала TortoiseSVN, а именно получения изменившейся части дерева проекта с учётом вложенности каталогов.
Вручную же собирать это дело, глядя на вывод svn diff --summarize надоедает уже на третий раз.
а че не в тематический блог написано?
Кстати если сервер выделенный (можно поставить svn), например тестовый, то можно использовать svn клиент на сервере.
И командой svn up апдейтить рабочую копию на сервере. А еще можно cruise control поставить…
И командой svn up апдейтить рабочую копию на сервере. А еще можно cruise control поставить…
В-общем, тоже выход.
Однако, на продакшене будут лежать «мусорные» каталоги .svn, что мне не нравится.
Да и к тому же если мне нужно обновить функциональность не просто до какой-то ревизии, а допустим только 3-4 и 9-11 (условно обозначим номера ревизий), при этом нельзя допустить заливку 5-8, то как-то получается неудобно.
Конечно, дело можно поправить, проводя изменения только в бранчах, а то что нужно залить мержить в транк… Но вот пока я до этого не дошёл. Ну и .svn как-то совсем не радует.
Да и не стоит забывать, что на девелоперском сервере и боевом в проекте разные ini, которые так же хранятся в svn. При обновлении точно могут возникнуть проблемы.
Однако, на продакшене будут лежать «мусорные» каталоги .svn, что мне не нравится.
Да и к тому же если мне нужно обновить функциональность не просто до какой-то ревизии, а допустим только 3-4 и 9-11 (условно обозначим номера ревизий), при этом нельзя допустить заливку 5-8, то как-то получается неудобно.
Конечно, дело можно поправить, проводя изменения только в бранчах, а то что нужно залить мержить в транк… Но вот пока я до этого не дошёл. Ну и .svn как-то совсем не радует.
Да и не стоит забывать, что на девелоперском сервере и боевом в проекте разные ini, которые так же хранятся в svn. При обновлении точно могут возникнуть проблемы.
Аргумент cleanup команды svn специально чтобы вас обрадовать сделали.
UFO just landed and posted this here
Попробуйте svn export, вам должно понравиться :)
hint: svn help export
hint: svn help export
ну а разве сложно сделать так, чтобы сайт подхватывал инишники в зависимости от продакшена/девелопмента? и головная боль с автоматической выкаткой на живой в плане подключения разных инишников отпадет сама собой
Вообще достаточно странный подход заливать отдельные файлы проекта для релиза. Может стоит пойти в сторону более четко сформулированных релизов? Где релиз есть атомарная единица — четко характеризующася ревизией в репозитории и подразумевающую полную перезаливку файлов из нужной ревизии применяя попутно нужные проперти файлов? А обозначенные варианты — залить кусочек проекта куда то — это не серьезно — у вас в транке всегда должна лежать живая версия, которая находиться в продакшене.
Поддерживаю вашу идею об атомарности релизов: релиз = версия в SVN — правильный подход. Но вот идея о том, что «в транке всегда должна лежать живая версия, которая находиться в продакшене» выглядит несколько странно.
В транке традиционно находится головная версия разработки. На сколько она «валидна» определяется процессами автоматической сборки и автоматизированного тестирования.
Версии же, находящиеся в production, помечаются соответствующими тегами. А при необходимости внести фикс непосредственно в production, есть смысл сделать branch в svn и исправить там.
Так у вас всегда будет доступ как к головной версии разработке, так и к той версии, которая ушла на production, со всеми изменениями, патчами и хотфиксами.
В транке традиционно находится головная версия разработки. На сколько она «валидна» определяется процессами автоматической сборки и автоматизированного тестирования.
Версии же, находящиеся в production, помечаются соответствующими тегами. А при необходимости внести фикс непосредственно в production, есть смысл сделать branch в svn и исправить там.
Так у вас всегда будет доступ как к головной версии разработке, так и к той версии, которая ушла на production, со всеми изменениями, патчами и хотфиксами.
В нашей организации есть следующий подход релизов и билдов. Каждую неделю у нас выходит билд — в среду заморозка кода для этого билда и в пятницу пуш кода. Есть множество команд которые работают над своими ветками (ветки создаются из транка в момент создания проекта — точнее подпроекта для главного проекта). Что происходит — за месяц — два до намеченного выхода вашей версии — вы создаете бренч из транка и работаете в нем — ближе к релизу все команды мержжатся в ветку для этого релиза — потом релиз морозиться и тестируются, проходя несколько альфа релизов. Затем когда релиз готов — и зарелизин и все эмергенси баги зафикшены код заливается в транк. Идея иметь код в транке следующая — в условиях конкурентных проектов, вы не можете знать что и как происходит. И надо всегда иметь отправную точку.
Для справки — у нас порядка 140 девелоперов и десятка три конкурентных проектов для одного большого проекта — и поэтому иметь в транке весь мусор никак нельзя.
Для справки — у нас порядка 140 девелоперов и десятка три конкурентных проектов для одного большого проекта — и поэтому иметь в транке весь мусор никак нельзя.
Согласен. При разработке продукта такого масштаба — самый разумный подход. Описанный мною процесс работает для небольших команд, скажем, человек по 10-20.
Я сталкивался с выносом разработки по каждому релизу в бренч. В добавок, каждый дефект порождал свой бренч. Но все это уже плохо уживается с svn, в качестве инструмента использовался Rational Clear Case.
Скажите, у вас не наблюдается крупных проблем с множественным мержем в svn? Например, когда команды начинают сливать свои изменения в ветку релиза?
Я сталкивался с выносом разработки по каждому релизу в бренч. В добавок, каждый дефект порождал свой бренч. Но все это уже плохо уживается с svn, в качестве инструмента использовался Rational Clear Case.
Скажите, у вас не наблюдается крупных проблем с множественным мержем в svn? Например, когда команды начинают сливать свои изменения в ветку релиза?
А что у вас понимается под конкурентным проектом? это версии одного и того же продукта? тогда почему в транке не лежит самая последняя версия? Ведь идея в том, что в транке должны находиться наиболее поздние версии приложения. Я не прав? может специфика вашего приложения как-то влияет на структуру репозитория, если да, то как именно? Есть ли какие-то особенности кроме вышеописанных? Что имеется в виду под «отправной точкой»? Почему бранчи не могут быть просто по возможности максимально независимыми (если это ведение того, что вы называете «конкурентным проектом»)?
Судя по написанному вами, у вас в компании вполне адекватный подход к ведению репозитория. Интересуюсь, может еще что-то полезное могу для себя извлечь.
Судя по написанному вами, у вас в компании вполне адекватный подход к ведению репозитория. Интересуюсь, может еще что-то полезное могу для себя извлечь.
Ну в проекте 2500 файлов и из-за того что изменилось штук 10 всё перезаливать сильно долго.
Почему не rsync?
SmartSVN + SmartCVS + SmartSynchronize (http://www.syntevo.com/)
Прекрасная разработка, правда для нашего проекта оказалась великоватой, — для однократного использования это как танк окупать для проезда в магазин за хлебом :)
Прекрасная разработка, правда для нашего проекта оказалась великоватой, — для однократного использования это как танк окупать для проезда в магазин за хлебом :)
Sign up to leave a comment.
Умный экспорт из SVN с помощью консоли