Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Система контроля/управления версиями вам не подходит?
Задача заключается не столько в контроле версий, сколько просто в обеспечении работоспособности кода в рабочем проекте. В команде кроме меня еще один человек, и каждый в основном редактирует только свой код (разные приложения). На всякий случай предусмотрен ежедневный бэкап, но пока он, к счастью, ни разу не пригодился :)
Контроль версий это не просто контролирование версий. Это и тот самый бекап, потому что если вы что то в своём коде сломаете, то всегда можно откатится. Это и возможность посмотреть — а почему оно три дня назад работало, а сейчас нет. Причем легким движением руки вы именно увидите различия. А уж про синхронизацию наработок с напарником я вообще молчу.
Вот только svn уже не мейнстрим, сейчас в моде распределенные системы — git, mercurial, bazaar и тп. Обязательно прочтите про них, прямо сейчас — сэкономите много времени и сил на ненужные движения.
А скрипт это всегда хорошо — развивает мышление, хоть и велосипед. Но где то я читал, что велосипеды обязательно надо писать — начинаешь понимать, в чем собственно сложность прикрутить вот ту фичу, которая уже год в багзиле висит.
Вот только svn уже не мейнстрим, сейчас в моде распределенные системы — git, mercurial, bazaar и тп. Обязательно прочтите про них, прямо сейчас — сэкономите много времени и сил на ненужные движения.
А скрипт это всегда хорошо — развивает мышление, хоть и велосипед. Но где то я читал, что велосипеды обязательно надо писать — начинаешь понимать, в чем собственно сложность прикрутить вот ту фичу, которая уже год в багзиле висит.
Нужно только смотреть измененные/добавленные файлы или обновлять сервет тоже нужно?
Не проще ли для этих нужд использовать тот же SVN — в режиме Dry Run при выполнении Merge он показывает ту же инфу что и ваш скрипт.
Если же нужно просто обновлять, то стандартный rsync -av [src] [dest] вполне пригоден.
Не проще ли для этих нужд использовать тот же SVN — в режиме Dry Run при выполнении Merge он показывает ту же инфу что и ваш скрипт.
Если же нужно просто обновлять, то стандартный rsync -av [src] [dest] вполне пригоден.
$ diff -r intranet myproject| grep ^Only
$ diff -r intranet myproject| grep ^diff
не то же самое делает?
$ diff -r intranet myproject| grep ^diff
не то же самое делает?
Я использую Araxis Merge для сравнения каталогов и файлов.
скарипт написан неаккуратно.
1. f_src.find('.pyc') -почему find а не enswith
2. почему неьзя было написать вместо
просто f_str.startswith(check_list)
3. Зачем вообще обходить все дерево, если нам нужны только несколько папок?
сожно написать что-то типа:
for root, dirs, files in sum(map(os.walk, check_list), [])
или просто добавить еще один for
4. f_src.replace(«myproject», «intranet») — что будет делать при наличии файла myproject.py
1. f_src.find('.pyc') -почему find а не enswith
2. почему неьзя было написать вместо
for item in check_list:
if f_src.find(item) != -1:
need_check = True
break;
просто f_str.startswith(check_list)
3. Зачем вообще обходить все дерево, если нам нужны только несколько папок?
сожно написать что-то типа:
for root, dirs, files in sum(map(os.walk, check_list), [])
или просто добавить еще один for
4. f_src.replace(«myproject», «intranet») — что будет делать при наличии файла myproject.py
1, 2 — исправил, 3,4 — чуть позже проверю.
Спасибо за отличный комментарий! Все-таки блог называется «Язык программирования Python» :)
Спасибо за отличный комментарий! Все-таки блог называется «Язык программирования Python» :)
теперь == -1 — лишнее
я бы еще подумал как присопособить filecmp.dircmp для ваших нужд например можно взять за основу
из C:\Python30\Lib\filecmp.py
я бы еще подумал как присопособить filecmp.dircmp для ваших нужд например можно взять за основу
def report_full_closure(self): # Report on self and subdirs recursively
self.report()
for sd in self.subdirs.values():
print()
sd.report_full_closure()
из C:\Python30\Lib\filecmp.py
4:
f_src.replace("myproject", "intranet", 1) для замены 1 раз.
Если в копии проекта будет удален файл, Ваш скрипт об этом не узнает.
Предвижу следующую статью: «Рекурсивное перенесение изменений на рабочий хост» :)
Потратье лучше немного времени и изучите SVN — крайне полезная вещь даже если работаете в одиночку.
Потратье лучше немного времени и изучите SVN — крайне полезная вещь даже если работаете в одиночку.
И почему большая часть комментариев про системы контроля версий? :) Поймите меня правильно, не имею ничего против SVN, тем более, что доводилось работать с этой системой. Но ведь не случайно данный пост помещен в блог о программировании на Python.
Мне показалось интересным, что данную задачу можно решить так просто и красиво, вот и все. Воспринимайте это как небольшую демонстрацию, которая может быть интересной тем, кто изучает Python. В последнее время все чаще стали появляться статьи об этом замечательном языке. Это радует, но хотелось бы видеть больше практических примеров, в которых решаются какие-нибудь пусть несложные, но реальные задачи, поэтому я и выбрал такую тему для статьи.
Мне показалось интересным, что данную задачу можно решить так просто и красиво, вот и все. Воспринимайте это как небольшую демонстрацию, которая может быть интересной тем, кто изучает Python. В последнее время все чаще стали появляться статьи об этом замечательном языке. Это радует, но хотелось бы видеть больше практических примеров, в которых решаются какие-нибудь пусть несложные, но реальные задачи, поэтому я и выбрал такую тему для статьи.
Я не против вашего решения. Вообще решений может быть масса. Все зависит от того, что именно вы решаете: практическую задачу контроля файлов или учебно-теоретическую по работе с файлами в питон.
Потому что на практике возникнет масса нюансов — например, как отслеживать переименование/удаление файла? Иногда помимо обнаружения изменений, надо посмотреть историю, откатить на несколько шагов. Как быть когда откат должен совершиться сразу в двух файлах? Например, вы изменили библиотеку и изменили функцию, которая ее использует. Надо проверить все файлы где она есть, иначе «сломается». То есть не все проблемы практики можно решить простым скриптом.
А в качестве демонстрации работы с питоном — отличная задача!
Потому что на практике возникнет масса нюансов — например, как отслеживать переименование/удаление файла? Иногда помимо обнаружения изменений, надо посмотреть историю, откатить на несколько шагов. Как быть когда откат должен совершиться сразу в двух файлах? Например, вы изменили библиотеку и изменили функцию, которая ее использует. Надо проверить все файлы где она есть, иначе «сломается». То есть не все проблемы практики можно решить простым скриптом.
А в качестве демонстрации работы с питоном — отличная задача!
Откат изменений, сделанных в нескольких файлах, это действительно удобная штука, согласен с вами. Странно, но теперь я и сам чудесным образом начинаю верить, что мне необходима система контроля версий — осталось только определиться с выбором. А пока выбираю, этот скрипт еще послужит, все-таки люблю я простые решения, от которых пользы много, а затрат почти никаких :)
Если использовать filecmp, то задачу можно решить проще, используя filecmp.dircmp. Он за вас всю работу сделает, вам понадобится только отфильтровать (что бы не показывать .pyc) left_only или right_only и diff_files.
a) unison.
b) bzr.
c) waf/scons
любой из этих инструментов позволяет сделать все куда грамотнее. А вообще по идее на «боевом» сервере никогда в жизни не надо менять код. Поэтому намного эффективнее сделать бранч в базаре для него, скинуть на сервак и пулить периодически. А уж использовать систему билдинга (waf/scons) и просто делать install — верх совершенства, который может ещё и тесты прогнать автоматом перед инсталлингом изменённых файлов.
b) bzr.
c) waf/scons
любой из этих инструментов позволяет сделать все куда грамотнее. А вообще по идее на «боевом» сервере никогда в жизни не надо менять код. Поэтому намного эффективнее сделать бранч в базаре для него, скинуть на сервак и пулить периодически. А уж использовать систему билдинга (waf/scons) и просто делать install — верх совершенства, который может ещё и тесты прогнать автоматом перед инсталлингом изменённых файлов.
ауч. прочитал что вы раньше имена изменённых файлов в блокнот писали.
простите за то непонятное что я написал комментом выше. Пока рано)
простите за то непонятное что я написал комментом выше. Пока рано)
Использую bzr на работе и subversion на google code для одного своего проекта )
Правда получилось так, что в итоге использую bzr как svn, даже более того — только локально. Рабочий код — lightweight checkout. Вы пишете о том, что надо сделать бранч, какие преимущества это может дать в моем случае?
Правда получилось так, что в итоге использую bzr как svn, даже более того — только локально. Рабочий код — lightweight checkout. Вы пишете о том, что надо сделать бранч, какие преимущества это может дать в моем случае?
trunk — там самое основное
prod — сюда мержится из транка только то что «оттестировано» и надо вливать на серв
на сервере bzr pull prod — и потом только пулить хоть каждые пять минут ).
собсна trunk ->(ручной мерж + проверки) -> prod -> (автоматический мерж/или ручной — не важно) -> production_server. При этом в транке можете экспериментировать сколько душе угодно, а вот prod — уже стейбл должен быть.
1. творите в trunk
2. рано или поздно думаете «ну вот вроде прекрасно все»
3. мержите транк в prod (тока скорее пулите, ибо в prod по идее своих изменений не должно быть)
4. идёте на серв и творите bzr pull.
всё. =) 4ю операцию можно автоматизировать, если хочется — т.е. автоматом пулить на сервере при закидывании в prod. Можно ваще работать в транке, потом мержить прямо на сервер o_0. Чтобы тут все гладко прошло — надо ставить плугин который bzr up после мержа удалённо запустит. Ну или самому его дергать через ssh.
prod — сюда мержится из транка только то что «оттестировано» и надо вливать на серв
на сервере bzr pull prod — и потом только пулить хоть каждые пять минут ).
собсна trunk ->(ручной мерж + проверки) -> prod -> (автоматический мерж/или ручной — не важно) -> production_server. При этом в транке можете экспериментировать сколько душе угодно, а вот prod — уже стейбл должен быть.
1. творите в trunk
2. рано или поздно думаете «ну вот вроде прекрасно все»
3. мержите транк в prod (тока скорее пулите, ибо в prod по идее своих изменений не должно быть)
4. идёте на серв и творите bzr pull.
всё. =) 4ю операцию можно автоматизировать, если хочется — т.е. автоматом пулить на сервере при закидывании в prod. Можно ваще работать в транке, потом мержить прямо на сервер o_0. Чтобы тут все гладко прошло — надо ставить плугин который bzr up после мержа удалённо запустит. Ну или самому его дергать через ssh.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скрипт для рекурсивного сравнения директорий