После долго молчания, возвращаемся к нашим баранам.
Во первых, что обязательно нужно описать, так это передвижение с google-code на launchpad. Предпосылки:
- во-первых плюсы DVCS системы:
- банальные мелочи, у меня есть четыре машины с которых я колбашу код. Естественно, я один, про фитчи думаю один, изменения архаичные, некоторые нужно сразу в главную ветку, другие - только в бранчи. В свн-бранчи все оформлять тупо лень (т.к. о них нужно помнить). По этому колбашу в trunk-е. И синхронизировать 4 машины ой какая проблема - типа вчера уснул и часть не закомитил, а изменения были эпические. Работа встала на других машинах. В распределенной системе - каждая локальная копия по-сути бранч. Работотать на нескольких машинах в разы проще.
- смерджить можно все что угодно, без последствий. В свн-е же для мерджа нужные крепкие нервы и холодные разум.
- можно без проблем откатиться до любой версии. Кто как, но я это люблю.
- во-вторых плюсы launchpad-а:
- bazaar собственно.
- Хостинг многих опен-сурс проектов, которые я использую (хотя бы убунта и терминатор)
- всякие бонусы типа отображения публичного gpg ключа и активности пользователь.
- есть публичная страничка на которой отображены все проекты пользователя. В гугль-коде такую не нашел. Мне это критично.
- давно хотел провести глобальные изменения архитектуры
- есть мой хостинг (пока не рассекреченный), крутится ngnix, заведен джанго-проект. В нем крутится homebudget (как не трудно догадаться). Иногда мне нужно добавлять новые приложения для личных целей (скорее не целей, а идей и экспериментов). Заводить новый процесс под это ой как не хочется, да и не логично. А в старой структуре свн-а был заведен репозиторий прямо на проект, и лежащие внутри приложения. Новые приложения хранятся (или не хранятся вовсе) в разных местах. Ну вот и логичнее всего мне вести репозитории по приложениям, а не по проекту. Так что от репозиторя для проекта было решено отказаться в пользу локального репозиторя. А приложения - в народ.
- Еще один плюс приложений - манипулировать гораздо проще. Развертываешь в отдельной папке такую-то ревизию, ставишь на нее симлинк, а старый затираешь. Круто, да круто.
- Хотя нужно сказать структура проект-приложение не совсем гибкая. Это не удобно, тупо не удобно. Нужно больше ветвления. Типа переиспользуемые под-приложения.
Как это делалось, да просто как можно догадаться.
- изменил все межпроектные линки на использование глобальных "homebudget.purchases" и "homebudget.tagsfield"
- вынес маппинг урлов из проектого urls.py в соответствующие файлы приложений. В проектном urls.py теперь стоит просто include bla-bla-bla.
- разместил статик контент и темплейты по директориям проектов (т.е. было "homebudget/content/purchases/css", стало "homebudget/purchases/media/css" и тд)
- в новый проект добавляется директория типа "static-content", в нее ставятся симлинки на директории "homebudget/purchases/media". MEDIA_ROOT смотрит на директорию "static-content". В итоге: из проекта до его статик файлов можно достучаться по пути "/site-media/purchases/css/" (работает MEDIA_URL, имя проекта, и путь по симлинке).
- темплейтные директории прописываются явно в settings.py в TEMPLATES_DIR (типа "/homebudget/purchases/templates/"). Соответствующий код для взятия темплейтов был подправлен.
- ну и проекты были добавлены в PYTHONPATH, типа "export PYTHONATH=${PYTHONPATH}:/path/to/project" где-то внутри "~/.bashrc"
Собственно ссылки:
- https://code.launchpad.net/~alexa-infra/+junk/homebudget - новый репозиторий
- http://code.google.com/p/homebudget-site/ старый репозиторий (будет апдейтиться по ключевым моментам, но рабочие измениния в нем не найти)
Посты по теме:
Комментариев нет:
Отправить комментарий