Tag Archives: git

Mercurial саторі. Частина 1

Скоро мені знадобиться знайомити одного майбутнього молодого розробника з таїнством користування системами контролю версій (надалі VCS, version control system) і тому щоб трохи систематизувати те, що я збирався розповісти, вирішив написати цей допис. Він розрахований на зовсім базовий рівень роботи і тому тут багато розжовувань, які більш досвідченим особам наврядчи будуть цікаві. Знайомство одразу буду проводити на прикладі сучасних розподілених систем, в нашому випадку Mercurial.

Навіщо воно треба?

Для людей які хоч трохи займались програмуванням відповідь має бути очевидною, але на всяк випадок нагадаю: під час роботи над чимось ви сто відсотків будете проходити якісь віхи розробки і контроль версій дозволить отримувати стан проекту на певний момент. Плюс можна створювати гілки розробки. Уявіть, що при побудові будинку ви вирішите добудувати якийсь незапланований поверх, але не впевнені чи все триматиметься як слід. Ви віртуально дублюєте поточний будинок, будуєте свій поверх, поки інші будівельники тим часом працюють по запланованому графіку. Потім ви вирішуєте, що результат вашої роботи вас влаштовує ви плеском в долоні вставляєте його у існуючий будинок. А може будівельники десь помилились при розрахунках і набудували якусь фігню, то вони можуть так само швидко відкотитись до місця коли щось пішло не так.
До речі, місце де зберігаютсья всі стани проекту в термінах VCS називаєтсья репозитарій, а місце в якому ви вносите правки – відповідно робоча копія. Процес відправки набору змін з робочої копії до репозиторію – це операція commit. Репозитарії часто зберігають десь подалі, не на робочих машинах, щоб у випаку коли у вас, наприклад, здохне комп, весь код можна буде повіністю відновити. У мене був гіркий досвід збереження єдиного екземпляру коду одного сайту на ноуті, який згодом сперли… З тих пір я не розлучний -з VCS та бекап-системами типу Dropbox і зберігаю всі важливі дані в інтернеті. Плюс зручно, що можна з легкістю отримувати точні копії на будь-яку машину.
І нарешті ще одна зручна штука в користуванні VCS, хоч і похідна від нього – це можливість робити code review – огляд змін які зробив розробник між версійми коду. Принципироботи code review-систем чудово накладаються на принципи роботи VCS і тому вони часто бувають нерозлучні, коли якість коду має велике значення.

Розподілені VCS

Як писалося вище, існують поняття репозитарію та робочої копії. У VCS, які були популярні донедавна було чітке розподілення обов’язків: репозитарій був один і центральний, часто на виділеному сервері. Кожний commit відправляв дані з робочої копії до репозиторію. В певному сенсі це було не завжди зручно у випадку, коли ви хочете закинути кілька змін різними commit’ами на сервер, що знаходиться в інтернеті. По перше, процес зазвичай досить повільний, по-друге, за відсутності зв’язку з інтернетом ви взагалі не зможете зробити commit.

Тому щоб побороти подібні недоліки прийшли розподілені системи контролю версій: Mercurial, Git, Bazaar, тощо… Суть їх проста: кожна копія проекту є одночасно і репозитарієм і робочою копією. Тобто вся робота по суті виконуєтсья локально, але існує механізм синхронізації між самотніми репозитаріями. За такої організації вищезгадані проблеми з відсутністю зв’язку з інтернетом нівелюються – ви можете робити весь спектр операцій з VCS локально. Але як я вже казав зберігати дані локально – небезпечно, тому зазвичай в інтернеті відкривають віддалені репозитарії, які слугують таким собі хабом між людьми які працюють з даними. Тобто синхроніхація репозитаріїв іде не кожен-з-кожним (хоча і такий принцип організації можливий), а всі синхронізуютсья лише з віддаленим (але навіть за його недоступності робота може продовжуватись).

Розподілених VCS є кілька. Найбільш популярні наразі Git та Mercurial. Вибір між ними справа релігійна, але якщо цікаво порівняти, то ось гарний аналіз від Google (англ).

Працюємо з Mercurial

Як я вже говорив, робоча копія Mercurial фактично є заодно і репозиторієм, але всі зрізи версій зберігаються в каталозі .hg з мета-інформацією репозиторія. Поза цією папкою власне робоча копія. Не видаляйте папку, бо втратите репозиторій!

Варіантів для отримання локального репозитарію проекту два:

  • якщо він існує на іншому комп’ютері чи сервері і тоді вам треба виконати команду clone: $ hg clone http://path/to/your/repository

вона створить копію репозитарію з вказоного URL в поточному каталозі

  • якщо ви створюєте новий проект, то потрібно виконати команду init в папці з проектом: $ hg init

потім додати всі потрібні файли командою add:

$ hg add

Увага! У вас в каталозі можуть бути файли, які не варто зберігати: наприклад, “.obj”-файли C++ чи Пітонівські “.pyc”.
для цього в кореневій папці (на одному рівні з папкою “.hg”) треба створити файл .hgignore з вмістом типу:

glob:*.bak glob:*.obj glob:Debug glob:Release

і так далі… Можна також прописувати не лише файли, а і цілі каталоги (Debug та Release в прикладі вище).

Далі можна працювати з кодом. Якщо додавались нові файли – не забувати виконувати команду add. Коли потрібно залити зміни в репозитарій виконуємо команду commit:

$ hg commit

Тепер варто трохи поговорити про синхронізацію репозитаріїв, але для цього треба зробити невеликий ліричний відступ. Із-за розподіленої архітектури дерево ревізій в Mercurial утворює досить цікаві завитки. В же централізованих системах дерево ревізій представляє собою ланцюжок. Тобто робота виглядає наступним чином:

  1. була деяка початкова ревізія №1, яку для подальшої роботи стягнули два розробники
  2. обидва щось поправили і один був першим, хто закомітив зміни на сервер, і з’явилась ревізія №2
  3. другий спробував закомітитись, але сервер відмовив, вказавши що не може залити зміни поверх версії №1. Тому другий розробник має забрати собі версію №2 з репозиторія та об’єднати (або як часто кажуть “змерджити” від англомовного терміну merge) докупи зміни з ревізії №2 та свої власні правки. Часто це проходить автоматично, але буває, що треба ручна правка, коли зміни торкаються однакових фрагментів коду. Потім об’єднаний код можна комітити в репозиторій і так з’явиться ревізія №3

Таким чином у централізованих системах є лише одна “головна” ревізія, а самі ревізії йдуть одна за одною. Ось так це виглядає схематично:

У розподілених систем нема центрального сервера, а всі коміти йдуть локально, тому типовий приклад роботи з ними наступний:

  1. є центральний хаб з якого два розробники забирають єдину ревізію №1
  2. обидва роблять правки та локальні коміти, таким чином і у першого, і у другого на комп’ютері з’являється по дві ревізії: загальна №1 і у кожного власна №2
  3. вони обидва синхронізують свої копії зі спільним репозитарієм і в результаті на спільному репозиторії з’являється три ревізії: №1, №2 та №3. Таким чином утворилося дві “головні” ревізії №2 та №3.
  4. один з розробників знову синхронізує репозиторій і у нього з’являєтясь копія спільного. Він може оновити локальну копію до однієї з головних ревізій і продовжити роботу в цій “підгілці”, а може об’єднати (змержити) зміни з №2 та №3 і закомітити їх як ревізію №4: таким чином граф ревізій утворить ромб.

Синхронізація в Mercurial однонаправлена: тобто за одну операцію можна або залити свої ревізії у віддалений репозиторій (операція push), або отримати звідти ревізії у свій локальний (операція pull).

$ hg pull http://path/to/your/repository $ hg push http://path/to/your/repository

Поки що це вся теоретична частина. Якщо ви працюєте під ОС Windows, то життя собі можна значно полегшити, якщо поставити собі TortoiseHg – графічний фронт-енд для роботи з Меркуріал. Плюс роботу можна зробити зручнішою та розширити потужність системи поправивши конфігураційний файл Mercurial. Про це в наступній частині.

Mercurial саторі. Частина 1

Скоро мені знадобиться знайомити одного майбутнього молодого розробника з таїнством користування системами контролю версій (надалі VCS, version control system) і тому щоб трохи систематизувати те, що я збирався розповісти, вирішив написати цей допис. Він розрахований на зовсім базовий рівень роботи і тому тут багато розжовувань, які більш досвідченим особам наврядчи будуть цікаві. Знайомство одразу буду проводити на прикладі сучасних розподілених систем, в нашому випадку Mercurial.

Навіщо воно треба?

Для людей які хоч трохи займались програмуванням відповідь має бути очевидною, але на всяк випадок нагадаю: під час роботи над чимось ви сто відсотків будете проходити якісь віхи розробки і контроль версій дозволить отримувати стан проекту на певний момент. Плюс можна створювати гілки розробки. Уявіть, що при побудові будинку ви вирішите добудувати якийсь незапланований поверх, але не впевнені чи все триматиметься як слід. Ви віртуально дублюєте поточний будинок, будуєте свій поверх, поки інші будівельники тим часом працюють по запланованому графіку. Потім ви вирішуєте, що результат вашої роботи вас влаштовує ви плеском в долоні вставляєте його у існуючий будинок. А може будівельники десь помилились при розрахунках і набудували якусь фігню, то вони можуть так само швидко відкотитись до місця коли щось пішло не так.
До речі, місце де зберігаютсья всі стани проекту в термінах VCS називаєтсья репозитарій, а місце в якому ви вносите правки – відповідно робоча копія. Процес відправки набору змін з робочої копії до репозиторію – це операція commit. Репозитарії часто зберігають десь подалі, не на робочих машинах, щоб у випаку коли у вас, наприклад, здохне комп, весь код можна буде повіністю відновити. У мене був гіркий досвід збереження єдиного екземпляру коду одного сайту на ноуті, який згодом сперли… З тих пір я не розлучний -з VCS та бекап-системами типу Dropbox і зберігаю всі важливі дані в інтернеті. Плюс зручно, що можна з легкістю отримувати точні копії на будь-яку машину.
І нарешті ще одна зручна штука в користуванні VCS, хоч і похідна від нього – це можливість робити code review – огляд змін які зробив розробник між версійми коду. Принципироботи code review-систем чудово накладаються на принципи роботи VCS і тому вони часто бувають нерозлучні, коли якість коду має велике значення.

Розподілені VCS

Як писалося вище, існують поняття репозитарію та робочої копії. У VCS, які були популярні донедавна було чітке розподілення обов’язків: репозитарій був один і центральний, часто на виділеному сервері. Кожний commit відправляв дані з робочої копії до репозиторію. В певному сенсі це було не завжди зручно у випадку, коли ви хочете закинути кілька змін різними commit’ами на сервер, що знаходиться в інтернеті. По перше, процес зазвичай досить повільний, по-друге, за відсутності зв’язку з інтернетом ви взагалі не зможете зробити commit.

Тому щоб побороти подібні недоліки прийшли розподілені системи контролю версій: Mercurial, Git, Bazaar, тощо… Суть їх проста: кожна копія проекту є одночасно і репозитарієм і робочою копією. Тобто вся робота по суті виконуєтсья локально, але існує механізм синхронізації між самотніми репозитаріями. За такої організації вищезгадані проблеми з відсутністю зв’язку з інтернетом нівелюються – ви можете робити весь спектр операцій з VCS локально. Але як я вже казав зберігати дані локально – небезпечно, тому зазвичай в інтернеті відкривають віддалені репозитарії, які слугують таким собі хабом між людьми які працюють з даними. Тобто синхроніхація репозитаріїв іде не кожен-з-кожним (хоча і такий принцип організації можливий), а всі синхронізуютсья лише з віддаленим (але навіть за його недоступності робота може продовжуватись).

Розподілених VCS є кілька. Найбільш популярні наразі Git та Mercurial. Вибір між ними справа релігійна, але якщо цікаво порівняти, то ось гарний аналіз від Google (англ).

Працюємо з Mercurial

Як я вже говорив, робоча копія Mercurial фактично є заодно і репозиторієм, але всі зрізи версій зберігаються в каталозі .hg з мета-інформацією репозиторія. Поза цією папкою власне робоча копія. Не видаляйте папку, бо втратите репозиторій!

Варіантів для отримання локального репозитарію проекту два:

  • якщо він існує на іншому комп’ютері чи сервері і тоді вам треба виконати команду clone:
    $ hg clone http://path/to/your/repository

    вона створить копію репозитарію з вказоного URL в поточному каталозі

  • якщо ви створюєте новий проект, то потрібно виконати команду init в папці з проектом:
    $ hg init

    потім додати всі потрібні файли командою add:

    $ hg add

    Увага! У вас в каталозі можуть бути файли, які не варто зберігати: наприклад, “.obj”-файли C++ чи Пітонівські “.pyc”.
    для цього в кореневій папці (на одному рівні з папкою “.hg”) треба створити файл .hgignore з вмістом типу:

    glob:*.bak
    glob:*.obj
    glob:Debug
    glob:Release

    і так далі… Можна також прописувати не лише файли, а і цілі каталоги (Debug та Release в прикладі вище).

Далі можна працювати з кодом. Якщо додавались нові файли – не забувати виконувати команду add. Коли потрібно залити зміни в репозитарій виконуємо команду commit:

$ hg commit

Тепер варто трохи поговорити про синхронізацію репозитаріїв, але для цього треба зробити невеликий ліричний відступ. Із-за розподіленої архітектури дерево ревізій в Mercurial утворює досить цікаві завитки. В же централізованих системах дерево ревізій представляє собою ланцюжок. Тобто робота виглядає наступним чином:

  1. була деяка початкова ревізія №1, яку для подальшої роботи стягнули два розробники
  2. обидва щось поправили і один був першим, хто закомітив зміни на сервер, і з’явилась ревізія №2
  3. другий спробував закомітитись, але сервер відмовив, вказавши що не може залити зміни поверх версії №1. Тому другий розробник має забрати собі версію №2 з репозиторія та об’єднати (або як часто кажуть “змерджити” від англомовного терміну merge) докупи зміни з ревізії №2 та свої власні правки. Часто це проходить автоматично, але буває, що треба ручна правка, коли зміни торкаються однакових фрагментів коду. Потім об’єднаний код можна комітити в репозиторій і так з’явиться ревізія №3

Таким чином у централізованих системах є лише одна “головна” ревізія, а самі ревізії йдуть одна за одною. Ось так це виглядає схематично:

У розподілених систем нема центрального сервера, а всі коміти йдуть локально, тому типовий приклад роботи з ними наступний:

  1. є центральний хаб з якого два розробники забирають єдину ревізію №1
  2. обидва роблять правки та локальні коміти, таким чином і у першого, і у другого на комп’ютері з’являється по дві ревізії: загальна №1 і у кожного власна №2
  3. вони обидва синхронізують свої копії зі спільним репозитарієм і в результаті на спільному репозиторії з’являється три ревізії: №1, №2 та №3. Таким чином утворилося дві “головні” ревізії №2 та №3.
  4. один з розробників знову синхронізує репозиторій і у нього з’являєтясь копія спільного. Він може оновити локальну копію до однієї з головних ревізій і продовжити роботу в цій “підгілці”, а може об’єднати (змержити) зміни з №2 та №3 і закомітити їх як ревізію №4: таким чином граф ревізій утворить ромб.

Синхронізація в Mercurial однонаправлена: тобто за одну операцію можна або залити свої ревізії у віддалений репозиторій (операція push), або отримати звідти ревізії у свій локальний (операція pull).

$ hg pull http://path/to/your/repository
$ hg push http://path/to/your/repository

Поки що це вся теоретична частина. Якщо ви працюєте під ОС Windows, то життя собі можна значно полегшити, якщо поставити собі TortoiseHg – графічний фронт-енд для роботи з Меркуріал. Плюс роботу можна зробити зручнішою та розширити потужність системи поправивши конфігураційний файл Mercurial. Але це я залишу на наступний раз.

GitHub у поміч блогеру

Восьмикіт — талісман мережі GitHubЧастенько блогеру, пов’язаному з IT-сферою, доводиться писати коротенькі сценарії, або ж операції, необхідні для досягнення бажаного результату. Зазвичай для подібних речей блогер ставить плагін для підсвітки синтаксису і самотужки вставляє шматки коду між спеціальними тегами. Однак щойно наш робочий скрипт змінився, чи з’їхала нумерація, як тут же всі вставки коду в статті доводиться переробляти наново.

Проте хочеться, щоб це виглядало максимально зручно для кінцевого читача. Однак і робити щоразу дурну роботу ліньки. Або ж хочеться описати деякі важливі моменти, а в кінці статті дати посилання на повністю готовий код. Або, описуючи власні дії покроково, дати користувачеві можливість просто-таки повністю скопіювати всі рядки разом, а не кожен окремо. Мало чого може залізти в голову блогеру.

Проте всі ці (і на разі не лише мої) забаганки можуть здійснитися, якщо використовувати GitHub, і, зокрема, сервіс Gist Read more »

Управління проектами з Trac

Задача: отримати багатоцільове open-source середовище для управління проектами з web-інтерфейсом, підтримкою Git та БД PostgreSQL, автентифікацією через LDAP.

Обираємо систему управління проектами

За інформацією для роздумів гугл нас привів на сторінку з вікіпедії. Як бачимо, вибір у нас досить великий. Вибрати з них що-небудь по собі з виконанням більшості критеріїв досить нескладно. Однак підтримку Git має в своїй реалізації лиш один проект — Trac, про який і йтиме мова далі.

Чому Trac

Trac logo

Версія 0.11
Мова Python
Сайт http://trac.edgewall.org/
Ліцензія Модифікована ліцензія BSD

Як вже було сказано, лише в нього я знайшов підтримку Git репозиторіїв. До того ж Trac має неабияку гнучкість: окрім базового набору, якого зазвичай не вистачає, купа функціоналу реалізована у вигляді плагінів, яких тут можна знайти на будь-який смак. Простий та зрозумілий з першого погляду інтерфейс, відсутність зайвих “свистілок” не може не порадувати людей, які від продукту очікують ефективну реалізацію функціоналу. Можливість адаптувати середовище на власний смак та за потребами проекту, будь то розробка програмного забезпечення, адміністрування, чи організація господарських робіт у себе на городі. Хоча незважаючи на можливість вести будь-які проекти в цій системі, все ж вона тісно інтегрована з ситемами контролю версій(Svn, Bazaar, Mercurial, Git), підсвіткою синтаксису “на льоту”(використовуються SilverLight, Enscript, а з версії 0.11 — ще й Pygments), розробкою документації (Doxygen, PyDoc, PerlDoc), і навіть системою управління тестами. Підтримка RSS-стрічок, wiki(до якої є теж купа розширень), і навіть ведення блогу додають практично всі необхідні інструменти для ведення сучасного проекту. Довершує все це добро документація по Trac, яка є в кожному новоствореному проекті на стоірнках wiki.

Установка та адміністрування

Ставити ми його будемо, звичайно ж, на Debian GNU/Linux, для якого поточною стабільною віткою вважається 0.10. Сподіваюсь, ви вже маєте налаштований Git репозиторій, інакше раджу взяти низький старт з цієї сторінки. Виконавши aptitude install apache2 libapache2-mod-python trac-core trac-git pcycopg2 та встановивши залежності й додаткові пакети за бажанням переходимо власне до конфігурації.

Першим кроком буде створення нового проекту. Де тримати проекти — справа кожного, хоча мені більше імпонує покласти їх до /var/trac/. Для промислового розгортання буде доцільним розгортати подібні середовища в домашніх директоріях користувачів. Отже, почнемо.

# mkdir /var/trac
# cd /var/trac
# trac-admin myproject initenv

В процесі установки система необхідно ввести деякі базові настройки, вибрати БД, з якою працюватимете, та вказати шлях до репозиторію. Якщо в якості репозиторію ви вказали Git, то система в кінці видасть попередження про відсутність його підтримки, однак все це можна сміливо ігнорувати, бо все це ми виправимо в подальших кроках.

trac-admin management utilityСаме з цього моменту починають проявлятись особливості роботи з Trac: адміністрування проекту проводиться за допомогою консольної утиліти trac-admin. Отже, якщо ви не маєте доступу через SSH до свого сервера, годі й мріяти про установку цієї системи. І хоча деякі операції можливо перекласти на веб-морду, однак початкову ініціалізацію — зась. Якщо ж ви все ще з нами і вже готові до наступного кроку, то не гаймо часу.

Всі налаштування проекта знаходяться в одному файлі conf/trac.ini в директорії проекту. Зараз можна підправити загальні параметри проекту, однак я раджу відкласти цей крок на момент після тестового запуску проекту. Справа в тому, що будь-який згенерований проект з самого початку містить wiki-документацію, яка доступною мовою опише можливості та особливості налаштування системи. Знову повертаючись до Git, на сторінці GitPlugin ви зможете прочитати вичерпні пояснення щодо того, яким чином організувати співпрацю Trac та Git.

Для успішного старту проекту необхідно отримати можливість запускати Python-івські скрипти на запит веб-сервера. Це можна реалізувати через механізм CGI, FastCGI, або ж використовуючи mod_python, що ми, власне, і зробимо:

<Location/projects>
  SetHandler mod_python
  PythonInterpreter main_interpreter
  PythonHandler trac.web.modpython_frontend
  PythonOption TracEnvParentDir /var/trac
  PythonOption TracUriRoot /projects
</Location>

Вище представлений шматок конфігураційного файлу веб-сервера, який дозволить вести нам безліч проектів, що лежатимуть в /var/trac Наступні рядки ж дозволять мати один обліковий запис для всіх проектів. Даний тип автентифікації приведений лише для прикладу. Автентифікація користувачів через систему LDAP буде описана в наступних статтях.

<LocationMatch"/projects/[^/]+/login">
  AuthType Basic
  AuthName "Trac"
  AuthUserFile /var/trac/.htpasswd
  Require valid-user
</LocationMatch>

Якщо всі кроки виконані успішно, ви мусите побачити вже працюючий проект за адресою:http://localhost/projects/myproject/

Додаткові плагіни

Деякі з плагінів потребують особливої уваги при роботі з ними. Тут розглянуті лиш два з них, хоча насправді проблеми можуть виникнути в багатьох плагінах, функціонал яких пов’язаний з іншими системами, зокрема плагіни, що реалізують автентифікацію.

GraphvizPlugin

Trac with GraphViz pluginТрохи помучитись змусив мене плагін, що реалізовує inline-вставку графічного представлення інформації за допомогою graphviz. Для тих, хто все ще не може отримати зображення, підкажу основні вимоги:

  • директорія, в якій знаходиться кеш graphviz повинна бути доступна для запису користувачем www-data, під яким запущено веб-сервер. Крім того, якщо ви використовуєте tmpfs, то не робіть директорію для кешу в /tmp, оскільки для роботи graphviz необхідне існування директорії, а при наступному ж перезавантаженні вона просто зникне.
  • необхідні пакети: graphviz та librsvg2-bin
WebAdmin

Для того, щоб не мати клопоту при роботі з цим плагіном, необхідно, щоб файли проекту в /var/trac/myproject були доступними користувачеві www-data для запису. Загалом же, плагін встановлюється та підключається без зайвих зусиль.

Trac та PostgreSQL 8.3

Якщо ви використовуєте Trac 0.10 зі стандартних пакетів Debian, то матимете клопіт з неможливістю перегляду звітів про помилки (tickets). При цьому ще й при додаванні такого звіту система може видавати помилки. Для того, щоб усунути цю помилку, необхідно змінити у файлі /usr/share/python-support/trac/trac/ticket/model.py рядок 296 з:

"ORDER BY time", (self.id, str(self.id), self.id))

на

"ORDER BY time", (self.id, str(self.id), str(self.id)))

Сподіваюсь, що за кілька днів після випуску даної статті ця порада стане непотрібною 😉

Висновки

Закінчуючи статтю, хочеться підбити підсумки щодо системи в цілому. Особисто я вже використовую Trac для власних проектів, тому що ця система:

  • проста, зручна, та ефективна
  • має підтримку сучасних репозитаріїв, баз данних та прикладного програмного забезпечення
  • дуже гнучка
  • знаходиться в активній розробці

Хочете переконатися в цьому самостійно? Тоді ласкаво просимо до http://www.hosted-projects.com/trac/TracDemo/Demo , де ви зможете попрацювати з Trac без зайвого клопоту.

Серед недоліків даної системи щодо нашого ринку можу віднести майже відсутній хостинг з підтримкою Python та неможливість організації повного циклу життя проекту від його зародження і до закриття через веб-інтерфейс, хоча останнє скоро буде виправлене.