Іменовані гілки проти кількох сховищ

Зараз ми використовуємо підрив на відносно великій кодовій базі. Кожен випуск отримує власну гілку, а виправлення виконуються проти магістралі та мігрують у гілки випуску за допомогоюsvnmerge.py

Я вірю, що прийшов час перейти до кращого контролю над джерелами, і я вже деякий час грав з Mercurial.

Здається, є дві школи, хоча вони керують такою структурою випуску за допомогою Mercurial. Кожен випуск отримує власне репо, і виправлення виробляються проти гілки випуску та висуваються на головну гілку (та будь-які інші новіші гілки випуску.) АБО використовуючи названі гілки в одному сховищі (або декількох збігаються копіях.)

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

Я прошу у вас; які відносні достоїнства кожного підходу?

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

Це означає, що клони чудово підходять для швидких експериментів, коли ви не хочете записувати ім'я гілки, а названі гілки корисні для довгострокових гілок ("1.x", "2.x" тощо).

Зауважимо також, що одне сховище може легко розмістити кілька легких гілок в Mercurial. Такі гілки в сховищах можуть бути закладені в закладки, щоб ви могли легко їх знову знайти. Скажімо, ви клонували сховище компанії, коли це виглядало так:

[a] --- [b]

Ви поредактіруете і зробити [x]і [y]:

[a] --- [b] --- [x] --- [y]

Середній час як хто - то ставить [c]і [d]в сховище, так що, коли ви тягнете ви отримаєте історію графа як це:

            [x] --- [y]
           /
[а Б В Г]

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

% hg parents

Скажімо, він повідомляє [y]. Ви можете бачити голови з

% hg heads

і це повідомить [y]і [d]. Якщо ви хочете оновити свій сховище до чистої каси [d], тоді просто зробіть (замініть [d]номером редакції для [d]):

% hg update --clean [d]

Потім ви побачите цей hg parentsзвіт [d]. Це означає, що ваш наступний комітет матиме [d]батьків. Таким чином, ви можете виправити помилку, яку помітили в головній гілці, та створити набір змін [e]:

            [x] --- [y]
           /
[a] --- [b] --- [c] --- [d] --- [e]

Щоб натиснути [e]лише зміни, потрібно зробити

% hg push -r [e]

де [e]хеш змін За замовчуванням hg pushбуде просто порівняти репозиторії і бачити , що [x], [y]і [e]не вистачає, але ви не хочете , щоб частка [x]і [y]ще.

Якщо виправлення також впливає на вас, ви хочете об'єднати його з вашою функцією:

% hg update [y]
% hg merge

Це дозволить графіку вашого сховища виглядати так:

            [x] --- [y] ----------- [z]
           //
[a] --- [b] --- [c] --- [d] --- [e]

де [z]є злиття між [y]і [e]. Ви також могли вирішити викинути гілку:

% hg strip [x]

Моя основна суть цієї історії в цьому: один клон може легко представляти кілька слідів розвитку. Це завжди було справедливо для "звичайного hg" без використання будь-яких розширень. Хоча розширення закладок - це чудова допомога. Це дозволить призначити імена (закладки) наборам змін. У випадку, що ви хочете, ви захочете закладку на вашій розробці та на верхній частині голови. Закладки можна переміщувати та витягувати за допомогою Mercurial 1.6, і вони стали вбудованою функцією в Mercurial 1.8.

Якби ви вирішили зробити два клона, ваш клон розвитку виглядав би , як це після того, як робити [x]і [y]:

[a] --- [b] --- [x] --- [y]

А ваш клон вище за течією буде містити:

[a] --- [b] --- [c] --- [d]

Тепер ви помітили помилку та виправите її. Тут вам не доведеться, hg updateоскільки клон вище за течією готовий до використання. Ви здійснюєте [e]:

[a] --- [b] --- [c] --- [d] --- [e]

Щоб включити помилку у свій клон розвитку, ви втягуєте його туди:

[a] --- [b] --- [x] --- [y]
           \
            [c] --- [d] --- [e]

і злиття:

[a] --- [b] --- [x] --- [y] --- [z]
           \ /
            [c] --- [d] --- [e]

Графік може виглядати інакше, але він має однакову структуру, і кінцевий результат той самий. Використовуючи клони, вам довелося зробити трохи менше розумових бухгалтерій.

Названі гілки насправді не ввійшли до малюнка, оскільки вони є необов’язковими. Сам Mercurial був розроблений за допомогою двох клонів протягом багатьох років, перш ніж ми перейшли до використання названих гілок. Ми підтримуємо гілку під назвою "стабільна" на додаток до гілки "за замовчуванням" і робимо наші випуски на основі "стабільної" гілки. Дивіться стандартну сторінку розгалуження у вікі для опису рекомендованого робочого процесу.

Я думаю, ви хочете всю історію за один репо. Нерестування короткострокового репо - це короткотермінові експерименти, а не основні події, такі як випуски.

Одне з розчарувань Mercurial полягає в тому, що, здається, не існує простого способу створити короткочасну гілку, пограти з нею, відмовитися від неї і збирати сміття. Гілки є назавжди. Я співчуваю тому, що ніколи не хочу відмовлятися від історії, але наддешеві одноразові гілки - це gitособливість, яку я дуже хотів би побачити hg.

Ви повинні робити і те, і інше .

Почніть з прийнятої відповіді від @Norman: Використовуйте одне сховище з однією названою гілкою за випуск.

Тоді мати один клон на гілку випуску для побудови та тестування.

Одне ключове зауваження полягає в тому, що навіть якщо ви використовуєте кілька сховищ, вам слід уникати transplantпереміщення наборів змін між ними, оскільки 1) він змінює хеш, і 2) він може вводити помилки, які дуже важко виявити, коли між набором змін змінюються конфліктні зміни трансплантації та цільової гілки. Ви хочете зробити звичайне злиття замість цього (і без прем'єру: завжди візуально перевіряйте злиття), в результаті чого @mg сказав наприкінці своєї відповіді:

Графік може виглядати інакше, але він має однакову структуру, і кінцевий результат той самий.

Більш докладно, якщо ви використовуєте кілька репозиторіїв, сховище "trunk" (або за замовчуванням, основне, розробка, будь-яке інше) містить ВСІХ наборах змін у ВСІХ сховищах. Кожне сховище випуску / гілки - це просто одна гілка в магістралі, всі об'єднані назад в одну сторону або назад назад до магістралі, поки ви не захочете залишити старий реліз позаду. Тому єдиною реальною різницею між цим основним репо і єдиним репо в названій схемі гілок є просто те, чи гілки названі чи ні.

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

Але тоді вам потрібно підтримувати один клон на гілку / випуск, який потрібно створити та протестувати. Це банально, як ви можете hg clone <main repo>#<branch> <branch repo>, і тоді hg pullу репо гілки витягуватимуться лише нові набори змін на цій гілці (плюс набори змін предків на попередніх гілках, які були об'єднані).

Ця настройка найкраще підходить для моделі Linux-ядра, що займається одним знімачем (чи не так добре діяти, як лорд Лінус. У нашій компанії ми називаємо рольовий інтегратор ), оскільки головне репо - це єдине, що розробникам потрібно клонувати, і знімач потрібно втягнути. Технічне обслуговування філійних репостів призначене виключно для управління випусками і може бути повністю автоматизовано. Розробникам ніколи не потрібно тягнути з / до гілки репостів.

Ось приклад @ mg, перероблений для цієї установки. Відправна точка:

[a] - [b]

Створіть названу гілку для версії релізу, скажіть "1.0", коли ви перейдете до альфа-релізу. Вчиніть на ньому виправлення помилок:

[a] - [b] ------------------ [m1]
         \                 /
          (1.0) - [x] - [y]

(1.0)не є реальним набором змін, оскільки названа гілка не існує, поки ви не скористаєтесь. (Ви можете зробити тривіальне зобов’язання, наприклад, додати тег, щоб переконатися, що названі гілки правильно створені.)

Злиття [m1]- це ключ до цієї установки. На відміну від сховища розробників, де може бути необмежена кількість заголовків, ви НЕ хочете мати кілька головок у вашому головному репо-рене (за винятком старої, мертвої гілки випуску, як згадувалося раніше). Отже, коли у вас є нові набори змін на гілках випуску, ви повинні негайно об'єднати їх до гілки за замовчуванням (або пізнішої гілки випуску). Це гарантує, що будь-яке виправлення помилок в одному випуску також міститься у всіх пізніших випусках.

Тим часом розвиток на гілці за замовчуванням продовжується до наступного випуску:

          ------- [c] - [d]
         /
[a] - [b] ------------------ [m1]
         \                 /
          (1.0) - [x] - [y]

І, як завжди, вам потрібно з’єднати дві голови на гілці за замовчуванням:

          ------- [c] - [d] -------
         /                         \
[a] - [b] ------------------ [m1] - [m2]
         \                 /
          (1.0) - [x] - [y]

А це клон 1,0 гілки:

[a] - [b] - (1.0) - [x] - [y]

Тепер вправа додати наступну гілку випуску. Якщо це 2.0, то він обов'язково відгалужує за замовчуванням. Якщо це 1,1, ви можете відключити 1,0 або за замовчуванням. Незважаючи на те, будь-який новий набір змін на 1.0 повинен бути спочатку об'єднаний у наступну гілку, а потім у типову. Це можна зробити автоматично, якщо немає конфлікту, що призведе до простого злиття.

Я сподіваюся, що приклад чітко пояснює мої попередні моменти. Підсумовуючи переваги цього підходу, є:

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

ОНОВЛЕННЯ hg сам робить це : основне репо містить стандартні та стабільні гілки, а стабільне репо - стабільний клон гілки. Однак він не використовує розгалужену гілку, оскільки теги версій у стабільній гілці досить хороші для цілей управління випуском.

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

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

Я б дуже радив не використовувати названі гілки для версій. Це дійсно для чого теги. Названі гілки призначені для тривалого відхилення, як stableгілка.

То чому б не просто використовувати теги? Основний приклад:

• Розвиток відбувається на одній гілці
• Щоразу, коли створено реліз, ви позначаєте його відповідно
• Розвиток просто продовжується звідти
• Якщо у певному випуску є деякі помилки, які потрібно виправити (чи що завгодно), ви просто оновите його до тегу, внесете зміни та введіть

Це створить нову неназвану голову на defaultгілці, ака. анонімна гілка, що ідеально чудово в рт. Тоді ви можете в будь-який момент об'єднати помилку, що починається, в основну доріжку розробки. Немає потреби в названих гілках.