Я ще один користувач Subversion, який бореться за перевиховання себе в Тао розподіленого контролю версій.
Під час використання Subversion я був великим шанувальником підходу, що стосується незначних проектів, і, з більшістю моїх колишніх роботодавців, ми би структурували наші відділення сховищ; теги та ствол:
branches-+
+-personal-+
| +-alice-+
| | +-shinyNewFeature
| | +-AUTOMATED-+
| | +-shinyNewFeature
| +-bob-+
| +-AUTOMATED-+
| +-bespokeCustomerProject
+-project-+
+-shinyNewFeature
+-fixStinkyBug
tags-+
+-m20110401_releaseCandidate_0_1
+-m20110505_release_0_1
+-m20110602_milestone
trunk
В межах самого власного дерева-джерела ми використали б (щось на зразок) таку структуру:
(src)-+
+-developmentAutomation-+
| +-testAutomation
| +-deploymentAutomation
| +-docGeneration
| +-staticAnalysis
| +-systemTest
| +-performanceMeasurement
| +-configurationManagement
| +-utilities
+-libraries-+
| +-log-+
| | +-build
| | +-doc
| | +-test
| +-statistics-+
| | +-build
| | +-doc
| | +-test
| +-charting-+
| | +-build
| | +-doc
| | +-test
| +-distributedComputing-+
| | +-build
| | +-doc
| | +-test
| +-widgets-+
| +-build
| +-doc
| +-test
+-productLines-+
| +-flagshipProduct-+
| | +-coolFeature
| | +-anotherCoolFeature
| | +-build
| | +-doc
| | +-test
| +-coolNewProduct
+-project-+
+-bigImportantCustomer-+
| +-bespokeProjectOne
| +-bespokeProjectTwo
+-anotherImportantCustomer-+
+-anotherBespokeProject
Ідея полягала в (і досі є) використати структуру сховища, щоб сприяти структуруванню зв'язку між інженерною командою; частина бізнесу, що стоїть перед клієнтами, та різні інші зацікавлені сторони та експерти в галузі.
На доцільність: вихідні документи, які розміщуються в одному з каталогів "проекту", використовуються (і заробляють гроші) лише один раз. Документи, що знаходяться в одному з каталогів "productLines", заробляють гроші стільки ж разів, скільки продається продукт з цього конкретного рядка. Документи, що знаходяться в одному з каталогів "бібліотек", заробляють гроші стільки разів, скільки продаються будь-які продукти, які ними користуються.
Це робить поняття амортизації витрат явним і допомагає розбудувати підтримку повторного використання вихідних документів у бізнесі.
Це також означає, що існує загальна структура, над якою можуть працювати наші засоби автоматизації побудови. (Наші сценарії побудови проходять у вихідному дереві, шукаючи папки «збирання», в яких вони знаходять файли конфігурації, вказуючи, яким чином повинен бути побудований кожен компонент; подібний процес відбувається і при створенні та тестуванні документації).
Важливо, що продукти, над якими я працюю, зазвичай займають ВЕЛИКИЙ час, щоб виконати тести вимірювання та характеристики продуктивності; від 20 до 200 годин; генерування десь від декількох ГБ до декількох ТБ оброблюваних результатів тесту / проміжних даних (які потрібно зберігати та прив’язувати до певної конфігурації системи, щоб покращити продуктивність з часом). Це питання робить управління конфігурацією важливим фактором, а також пред'являє певну вимогу до централізації, оскільки, як правило, обчислювальні ресурси, необхідні для виконання тестів на вимірювання та характеристики продуктивності, обмежені; (невелике скупчення 64-128 ядер).
Як одна фінальна примітка; система безперервної інтеграції знає, що їй потрібно викликати збірку; статичний аналіз; тест на дим і тестовий запуск блоку кожного разу, коли змінюється ствол, кожен раз, коли будь-яка гілка "тегів" змінюється, і кожен раз, коли будь-яка гілка "АВТОМАТИЧНА" гілка. Таким чином, окремі розробники можуть використовувати систему CI зі своїми персональними відділеннями, важливою здатністю, IMHO.
Тепер ось моє запитання: як я можу повторити все вищезазначене (і покращити його, якщо це можливо) за допомогою Mercurial.
--edit:
Моя теперішня думка полягає у використанні центрального сховища Subversion, для визначення загальної структури, але дозволити використання hg як клієнта, щоб розробники могли мати репост доступний на місцевому рівні.