?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Bazaar как SVN-клиент

Posted on 2011.04.05 at 14:22
Tags: , , ,
Предположим, вы хотите делать, например, периодическую выгрузку хранимых процедур и прочих объектов из сервера базы данных, и отслеживать изменения в SVN.

Так вот, самый простой и удобный способ это сделать - это воспользоваться Bazaar. :) Почему?

- Bazaar, в отличии от SVN, умеет определять переименования и перемещения файлов автоматически.
- Bazaar, в отличии от SVN, хранит свою информацию в одной папке в корне. А не в каждой подпапке. Что позволяет просто грохнуть все выгруженное дерево, и пересоздать его заново.
- Bazaar умеет работать с SVN-репозиториями как со своими собственными, и может быть использован как SVN-клиент.


1) Готовим папку для проекта в SVN-репозитории. Пусть это будет, скажем, https://sources/svn/server/trunk

2) Делаем ее чекаут:
bzr checkout https://sources/svn/server/trunk Server
cd Server

3) Пусть внутри Server перегенерируется дерево файлов с выгруженными объектами БД. Изменяются, добавляются, удаляются, переименовываются - неважно. Для коммита в SVN нам достаточно дать три команды:

Определим переименования:
bzr mv --auto

Учтем добавленные:
bzr add .

А удаленные удалятся сами:
bzr commit -F commit-message.txt < credentials

В файл credentials кладем пару логин-пароль, на разных строках. Не забываем дать enter в конце второй строки. И не забываем исключить этот файл из коммита:

bzr ignore credentials

Вообще - то, что для SVN-репозитория не запоминаются credentials - это косяк.

Далее, аккуратно раздаем на все права, заводим пользователя, под которым будет работать скрипт - и бинго. Все работает. Единственное - надо не забыть представить новозаведенного пользователя Базару. Сделать из под него следующее:



И все. Просто, и симпатично. Может, кому пригодится.

PS: Впрочем, для данной задачи совсем не обязательно хранить результат в SVN :). Bazaar-у практически без разницы - SVN-репозиторий по ссылке, или его родной, Bazaar-овский. Он формат SVN-репозиториев поддерживает родным образом -как свой собственный.

PPS: Для тех, кто переживает, что Базаар-хостингов в сети мало - или что Bazaar не является корпоративным стандартом - не переживайте. Любой SVN-хостинг или сервер - ваш.

Comments:


Кирилл Данилов
donz_ru at 2011-04-05 11:31 (UTC) (Link)
Git тоже умеет напрямую работать с SVN репозиториями. Почему был выбран именно Bazaar?
При работе с SVN репозиторием остаются ли плюшки DVCS в виде локальных коммитов?
vozbu
vozbu at 2011-04-05 12:13 (UTC) (Link)
Ага, читаю все плюсы Bazaar и думаю - ты это же git!
Gaperton
gaperton at 2011-04-05 13:28 (UTC) (Link)
А я вот читаю все плюсы git, и думаю - это ж bazaar!
aamonster
aamonster at 2011-04-05 12:57 (UTC) (Link)
Afaik просто автору больше нравится именно bzr. Так-то, кажется, для этой задачи bzr, git и hg равноценны.
Gaperton
gaperton at 2011-04-05 13:40 (UTC) (Link)
> Git тоже умеет напрямую работать с SVN репозиториями. Почему был выбран именно Bazaar?

Потому, что Bazaar действительно умеет работать с SVN репозиториями. А вот как именно и с какими тараканами это делает git - выяснять нет ни времени, ни желания. Главное - непонятно, зачем.

> При работе с SVN репозиторием остаются ли плюшки DVCS в виде локальных коммитов?

Я, видимо, плохо объяснил.

Bzr не git. В bzr, когда ты пишешь bzr checkout ..., и другую операцию, в которой указан URL репозитория, то нет никакой разницы, SVN-репозиторий по ссылке, или родной. Все операции работают практически одинаково. За мелкими исключениями, обусловленными объективной разницей в форматах хранения.

То есть, ответ - разумеется да. Для локального коммита, как и в обычной ситуации, достаточно сказать
commit --local
(Deleted comment)
Gaperton
gaperton at 2011-04-05 13:18 (UTC) (Link)
А почему, собственно, git?
(Deleted comment)
Иван Тищенко
t7ko at 2011-04-06 19:16 (UTC) (Link)
На моём проекте сейчас следующий workflow: есть trunk, куда летят все новые правки; есть production branch, который выложен на production server и работает на нём. Major version change означает что создаётся новый бранч, копия текущего транка. Minor version change означает что некоторые правки из транка мержатся в production бранч.

У меня простой вопрос к Вам как человеку, кто уже поюзал базар и может знать ответ сходу.

Вопрос: реализуется ли такой workflow в базаре -- без тех мерзких извращений и мук, которые мы терпим с мержами в svn? (похоже feature branch который они упоминают -- это то что мне нужно; но я не уверен... чтоб быть уверенным мне придётся прорыть всю их доку, потом ставить эксперименты... будет очень обидно, если в конце выяснится, что таки нет, низя такую чуду сделать)

(ЗЫ: корпоративный стандарт заставляет меня использовать svn. Если выяснится, что базар умеет такой воркфлоу поверх svn как repository format -- будет вообще идеально. Если умеет, но не в связке с svn -- всё равно хорошо, т.к. у меня будет очень сильный аргумент что на моём проекте корпоративный стандарт крайне неэффективен по сравнению с bzr.)

Заранее благодарен за совет.
Алексий
alexis_m at 2011-04-07 06:09 (UTC) (Link)
Можно поподробнее? Какие муки вы терпите с мержами в svn? :-)
я, конечно, не вижу всей картины, но то, что вы описали, это не feature branch, а все же release branch. Очень знакомая картина, поэтому и интересуюсь проблемами.
Согласен, отслеживать мержи из командной строки в svn удовольствие изещренное. А вот в TortoiseSVN (правда, windows) вполне удобно операции выполняются. Конечно, требуется некоторая дисциплиноровнносит разработчиков, чтобы комиты были по возможности изолированными - тогда проблем с мержем гораздо меньше.
Но я уверен, что дисциплинированность важны с любой VCS.
Иван Тищенко
t7ko at 2011-04-07 17:14 (UTC) (Link)
Хочу заранее предупредить, что возможно все проблемы от кривости рук и незнания "как их правильно готовить". Но факт есть факт -- проблемы эти у меня есть.

Первая проблема с мержами в svn -- это что хотя номинально он и поддерживает историю мержей (svn:mergeinfo), но по факту это крайне хрупкая и эфемерная конструкция. Неоднократно наблюдал, как от малейших толчков всё сыпалось. Они утверждают, что эта вещь позволяет им делать умные (автоматические) мержи бранчей друг в друга и в транк -- но у меня ни разу не получилось такой мерж выполнить. Вести разработку в двух ветках одновременно у нас также ни разу не получилось. Прямой и обратный мерж между ветками сразу же взрывает мозг и нам и svn, и слить всё в единый транк потом кроме как вручную нереально. Как минимум приходится записывать ревизии, когда и в какую сторону был мерж, чтобы потом при последующих мержах указывать эти ревизии (типа "мержить не от начала времён, а от ревизии Х которая была вмержена последний раз").

Вторая проблема с svn это что когда я хочу мержить -- я вынужден поднимать историю коммитов. Нет никакой возможности мержить пачками (именно тут feature branch судя по описаниям смотрится особо привлекательно).

Вообще, хочу поправить свой первоначальный вопрос -- я его не совсем правильно сформулировал. Базаром я хочу решать не столько проблемы с описанным в первом посте workflow: с ним мы и так вроде справляемся. Что нам сейчас всё более и более необходимо -- это та самая возможность вести разработку параллельно в двух и более ветках с общим предком. С возможностью не-ручного мержа их потом назад в одну ветку. А вопрос мой был -- смогу ли я мержить fix-by-fix буде мне это понадобится.

Т.е. я понимаю конечно, что это осуществимо как минимум так (очень нехорошо, но демонстрирует осуществимость):

$ cd {branch-to-merge-from}
$ bzr diff {specify-the-change-you-need} > patch.txt
$ cd {branch-to-merge-to}
$ patch < patch.txt

Интересно другое: 1) можно ли это делать непосредственно средствами базара, и 2) запомнит ли он информацию об этом мерже для использования в последующих мержах?

ЗЫ: Видимо придётся-таки читать. :( Не смог внятно объяснить проблему, только запутал всех.
Necromant [ath.cx] at 2011-04-07 05:31 (UTC) (Link)
Хех, базаар штука конечно удобная, но по сравнению с гитом тормознутая, увы. Когда попробовал Qt хранить в базааре, на моем атоме это было крайне медленно. Сейчас перешел на git, чем крайне доволен.
Кирилл Данилов
donz_ru at 2011-04-08 11:49 (UTC) (Link)
Проблем с авторизацией одновременно и на прокси, и на https репозитории не было? Базаар видит только один хост - конечного репозитория. Он понимает, что реалмы разные, но как правильно указать в конфигурационных файлах, не знаю. Там параметр реалм отсутствует. А воспринимать прокси как отдельный хост отказывается. Пока удалось авторизоваться в автоматическом режиме только на прокси. Вводить логин/пароль для репозитория каждый раз - не вариант.
Есть мысли, что можно сделать?
http://stackoverflow.com/questions/5594477/bazaar-cant-get-authorization-both-on-isa-proxy-and-on-repository-via-ssl - задал вопрос на стэке
Gaperton
gaperton at 2011-04-10 12:43 (UTC) (Link)
Были. Я вообще не смог одновременно пройти сквозь NTLM-proxy, и авторизоваться в SVN-репозитории через HTTPS. Может, что не так делаю. :) Без прокси - все работает.

И это очень досадно.

Думаю, придется пропатчить исходники bzr, чтобы добавить исключения для прокси. Скажем, для HTTPS - можно, думаю, заставить bzr игнорировать прокси в порядке исключения. Думаю, это не должно быть сложно. Хотя код пока не смотрел. В общем, руки дойдут - попробую.
Кирилл Данилов
donz_ru at 2011-04-10 17:09 (UTC) (Link)
В смысле не смог автоматически без ручного ввода или в принципе не получилось? Если последнее, то на стэке описал, как добиться только одного вопроса. Но, блин, как вот от него избавиться...
Изучать питон для меня не вариант. Да и ставить дополнительную софтину, которая полностью сокроет прокси, тоже не то - замаешься писать инструкции и консультировать, если сделать стандартным VCS в команде.
Похоже, у гита таки есть плюсы.
Previous Entry  Next Entry