LINUX.ORG.RU

Сайты в DVCS. Есть такое?

 , , ,


0

1

Задумал тут перенос своего http://www.airbase.ru на новые рельсы. Из каши файлов в ФС и локальном репозитории и таблиц БД сделать его исходники целиком в Mercurial. То есть логика такая:

— Исходные данные страниц сайта, картинки и прочее — лежат в файлах локального репозитория (это уже есть)
— При показе материалов движок берёт данные из локального репозитория, обрабатывает, транслирует разметку в HTML, ресайзит картинки и т.п., если нужно, кешируя, и отдаёт клиенту (это тоже есть)
— inotify-демон ловит изменения в локальном репозитории (пулы/чекауты) и, если нужно, регистрирует изменение (пересчитывает поисковый индекс, ведёт статистику, регистрирует embedded-объекты и т.п.), которое обычно было бы активировано при сохранении материала из браузера (это предстоит реализовать)
— Неплохо было бы прикрутить автопулл/чекаут по обнаружению изменения во внешнем репозитории. Тогда сайт бы сам обновлялся из репозитория после изменений разработчиками контента.
— Автоматом реализуется wiki-идеология (хотя потребуется обвязка для просмотра старых версий в рамках самого сайта), работу с данными можно сделать равноудобной как через браузер, по старинке, так и прямо на ФС (I ♥ mcedit). Да хоть через ftp, если сделать автокоммит.
— Ну и, наконец, opensource не только для кода, но и для контента получается :)

Но, может, я взялся за велосипед? И подобные решения уже есть?

★★★★★

Ответ на: комментарий от Anatolik

"-- Ага, — сказал Зигмунд."

«Бывают, доченька, и просто сны» © :)

На самом деле, как раз, такой подход в перспективе позволяет сделать реализацию статической части сайта на любом движке. Формат, который я использую, вообще с локлаьной генерации QBasic'ом во второй половине 1990-х начинался :) Потом — SP-Forth локально, Perl локально, Perl серверно и последние 10 лет — PHP :) Может, если получится Quercus к Play Framework прикрутить, то на последний плавно переползу.

По некоторым пунктам похоже на Jekyll

Беглый взгляд показал, что похоже, но лишь отчасти. Проще доделать то, что уже у меня есть, фактически, только автокоммиты, inotify и индексацию сделать.

KRoN73 ★★★★★
() автор топика

Ну что же, без всякой автоматики и индексирования оно у меня работает практически «из коробки». На пробу перенёс http://www.airbase.ru/hangar/planes/russia/su/su-27/radio/

Сейчас оно показывается из пуллов с https://bitbucket.org/Balancer/sites-airbase/src/87010780d2e1/hangar/planes/r...



Кстати, приятный бонус обнаружил — blame. Можно всегда увидеть, кто писал ту или иную часть материала без бегания по истории.

KRoN73 ★★★★★
() автор топика

Исходные данные страниц сайта, картинки и прочее — лежат в файлах локального репозитория (это уже есть)

VCS для картинок не нужна, если только это не что-нибудь динамично изменяющееся и составляющее одну из ключевых функций сайта вроде погодных карт циклонов, столбчатых диаграмм на бирже etc. VCS нужна для исходников, а картинки хранить через неё — только тормозить процесс накатывания версий. Советую отделить зёрна от плёвел, то бишь исходники от статичного контента, для которого лучше подойдёт rsync.

Deleted
()
Ответ на: комментарий от Deleted

VCS для картинок не нужна

Нужна для унификации коллективной работы с сайтом: Сайты в DVCS. Есть такое?

Советую отделить зёрна от плёвел, то бишь исходники от статичного контента

Исходники тут вообще не при чём, исходники движка — совсем другой проект. Речь именно о коллективной работе над контентом сайта.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

А, извините, не обратил внимание на «страницы».

Deleted
()
Ответ на: комментарий от KRoN73

если получится Quercus к Play Framework прикрутить, то на последний плавно переползу

*и треснул мир на пополам* о_О это же мерзкая жаба, как так после православного форта такую богомерзость выбирать? :(

hizel ★★★★★
()

Ух, как сложно-то.

  • Берётся любая static CMS, либо пишется своя за полчаса.
  • В mercurial настраивается incoming hook для обновления сайта после каждого push в репозиторий.
  • Если хочется проблем, в кронтаб добавляется «* * * */5 0 hg pull -u».

    Всё.

vasilenko ★★
()
Ответ на: комментарий от hizel

а что оно такое неживое?

Первая версия себя исчерпала, а во второй пока надобности нет :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от vasilenko

Всё

Вааще не то :) То есть в этом объёме оно и так, считай, уже есть.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от alienclaster

Буду велосипедить на Mercurial'е. Пока в ручном режиме, всё равно ещё в одиночку готовлю материалы. Автоматику уже по ходу добавлять буду. Возможно, с использованием DVCS-Autosync. Он, хоть, изначально под git заточен, но заявлена поддержка и Mercurial. Возможно, поковырять его будет лучше, чем совсем с нуля своё делать.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

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

alienclaster ★★★
()

Наконец, руки дошли до DVCS-Autosync. Нормально, завелось для Mercurial сразу. Так что теперь собственный локалхостовый Dropbox есть :)

Соответственно, работает синк сторонний пользователь <-> сайт. Правда, пока без активной работы с фреймворком со стороны репозитория, но это, как я понял, на хуках решается без всяких inotify.

Правда, DVCS-Autosync страшно мусорит в логах (в т.ч. трейсами на «OSError: [Errno 13] Отказано в доступе») и запускать приходится ручками, но первое можно потерпеть, под второе напишу ещё init-скрипты.

Жаль, что нельзя (или я не умею?) игнор по маске, а не по каталогу. А то как редактируешь прямо в репозитории из mc, так он мусорит .#* файлами, потом в логе автокоммита они (хотя самих их нет, понятно): http://hg.balancer.ru/site-airbase/

KRoN73 ★★★★★
() автор топика

Чёрт. При параллельном встречном изменении репозиториев автоматом плодятся ветки. Почему-то merge автоматом не вызывается.

Если ручками сделать hg merge и hg push — то всё возвращается в норму.

Никто не подскажет, может, через hgrc как-то задать явно можно?

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Кажется, проблема решается через hg fetch вместо hg pull.

Но теперь другая проблема. DVCS-autosync работает в одну сторону — от того, кто запустился вторым к первому. В обратном случае Jabber-бот обламывает с:

INFO:jabberbot:Ignoring message from unseen guest: balabot-dvcs-autosync@balancer.ru/AutosyncJabberBot on airbase
DEBUG:jabberbot:I've seen: [u'balabot-dvcs-autosync@balancer.ru/AutosyncJabberBot on home-server']

Типа, вторая машина после логина в XMPP регистрится на первой, но не наоборот.

KRoN73 ★★★★★
() автор топика

Пока автоматизацию никакую так и не сделал, но в полуавтоматическом (или полуручном, в зависимости от степени пессимизма) режиме уже функционирует.

Зазвал народ на http://www.balancer.ru/support/2012/11/t87006--novyj-format-razrabotki-sajtov...

Пока прежнего энтузиазма не видно :)

KRoN73 ★★★★★
() автор топика

С автоматизацией, кстати, кажется облом. DVCS Autosync не поставить на Windows. И потому для большинства юзеров идея автоматического обновления сайта окажется неработоспособной. Так что, наверное, даже и напрягаться особо не стоит.

Может, попробовать сделать обёртку через Dropbox? Правда, там объёмы смешные. Для типового пользователя будет только 2.5Гб. И это если он сам этим не балуется.

Там ни у какой свободной альтернативы Dropbox'у под свой сервер клиента под Windows не появилось?

KRoN73 ★★★★★
() автор топика

Вопрос синхронизации для простых юзеров, в том числе Windows, кажется, лучше всего решается через SparkleShare. Тот же Dropbox, только на своём GIT. Единственный минус, то, что клиент с сервера обновления получает не в реальном времени, как с Dropbox, а при коммите своих изменений.

Но для разработки сайта это, как раз, мало страшно.

KRoN73 ★★★★★
() автор топика

и да тебе что надо статический или динамический, если первое то их миллионы

qnikst ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.