Ми підривники, і ми хочемо знати переваги Mercurial [закрито]

Прочитавши, що я підривник Subversion, чому я повинен вважати чи не вважати Mercurial або Git чи будь-який інший DVCS .

У мене є пов'язане з цим питання. Я читаю це запитання і читаю рекомендовані посилання та відео, і бачу переваги, але не бачу, як говорять про загальну зміну розуму.

Наша команда складається з 8-10 розробників, які працюють над однією великою базою кодів, що складається з 60 проектів. Ми використовуємо Subversion і маємо основний магістраль. Коли розробник запускає новий випадок Fogbugz, він створює svn гілку, виконує роботу над гілкою і коли вони закінчуються, вони зливаються назад до магістралі. Іноді вони можуть залишатися на гілці тривалий час і зливати стовбур із гілкою, щоб отримати зміни.

Коли я спостерігав, як Лінус говорив про те, що люди створюють філію і ніколи більше не роблять цього, це зовсім не ми. Ми створюємо, мабуть, 50-100 відділень на тиждень без випусків. Найбільший виклик - це злиття, але ми також дуже добре в цьому. Я, як правило, зливається у випадку fogbugz & checkin, а не по всьому корінню гілки.

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

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

Чи є якась користь від DVCS, яку ми не бачимо, що може нам дуже допомогти?

Перефразовуючи своє запитання, "Якщо ми плануємо використовувати DVCS лише централізовано, які переваги це має?" Коли ви запитуєте це так, це не так. Одна гілка на кожне завдання надзвичайно поширена у СКС. Якщо ви задумаєтесь, наявність локальної робочої копії вихідного коду на машині розробника, яка змінюється незалежно від стовбура протягом дня, є гілкою, хоча ніхто не називає цього. Єдина відмінність між цим та вашим робочим процесом полягає в тому, що ви також даєте цим гілкам постійне ім'я на центральному сервері. Це не той вид розгалуження, про який говорять Лінус та інші.

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

Можливості безмежні. Всього лише один приклад, як щодо двох людей, що працюють на протилежних сторонах інтерфейсу? Їм потрібно регулярно ділитися кодом між собою, але це ще недостатньо стабільно, щоб поділитися з усіма. Вони можуть створити гілку, щоб поділитися між собою, а потім об'єднати її назад у центральний сховище, коли вона буде готова.

Можливість робити проміжні локальні послуги вартує всього цього самостійно. Це те, що ви просто повинні пережити для себе.

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

Для вашого конкретного випадку перехід на DVCS не має ніякої користі. Ви задоволені своєю існуючою системою, вона робить все необхідне, то навіщо переключатися? SVN все ще є активним проектом з відкритим кодом і має кращі, зріліші інтеграції з усіма основними IDE та інструментами розробки, ніж hg чи git. Враховуючи розмір вашої команди та кількість проектів, чи дійсно ви хочете витратити час на перетворення на новий інструмент, коли існуючий працює просто чудово?

Якщо у вас є розробники, які просто не можуть функціонувати без DVCS, вкажіть їх на svn шлюзи для hg або git. Дайте їм зрозуміти, що їх реєстрація в сховище svn повинна відповідати будь-яким процедурам та процесам, які використовує решта команди. Ще одна перевага цього підходу полягає в тому, що справжні джелоти DVCS, які вже використовують шлюзи, не повідомляючи, що тепер ви можете вийти з шафи :-).

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

З вашої точки зору, DVCS матиме такі значні переваги перед SVN:

• Після того, як ви клонували репортаж, багато операцій можна виконувати локально.
  • Переглядаючи журнал репозиторію, не потрібно торкатися до svn-сервера, тому це може бути неймовірно швидким.
  • Аналогічно, комутація гілок не вимагає доступу до сервера, а також локальних клонів.
• Оскільки гілки є лише різними шляхами історії, ваше сховище не захаращене будь-якою гілкою, яку кожен створив (у нас тільки справді є гілки випусків у SVN, але в branchesкаталозі все ще є багато підкаталогів, які вже не є актуальними).
  • У Git, як тільки гілку буде об’єднано назад і повернення буде видалено, ви, можливо, ніколи не дізнаєтесь, що вона навіть існувала.
  • У Mercurial у вас є вибір або назвати гілку (у такому випадку вона кодується у кожний набір змін на вічність), або просто створити неназвану (топологічну) гілку, яка спокійно злиється з історією, коли вона mergeповернеться в default( trunk)
• У SVN гілки гілок є занадто неясними, щоб бути корисними. В gitі hgвони просто збігаються з курсу.
• DVCS розуміють, що розробка програмного забезпечення - це DAG , тобто коли ви зливаєтесь, ви отримуєте набір змін із декількома батьками. SVN (принаймні версія, яку я використав) насправді цього не розуміє.

Останнє, ви кажете

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

При переході від використання hgвиключно з використанням в svnпоодинці , а потім gitsvnвін був мій досвід , що злиття є набагато простіше і без проблем безкоштовно hgі gitsvnчим вони з svn. Злиття з svn(принаймні, використовуваною нами версією) призводить до значно більшої кількості конфліктів, які потрібно вирішити вручну.

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

• текст із гілки, в яку ви зливаєтесь
• текст із гілки, в яку ви зливаєтесь

тоді як злиття з DVCS зазвичай дають вам третій варіант, який є

• текст спільного предка обох гілок, який ви зливаєте

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

Загалом, я б запропонував вам спробувати. З такими інструментами, як gitsvnі hgsubversion, ви навіть можете випробувати їх із вашими поточними репортами SVN .

^{Зауважте, створення клону, в першу чергу, є королівським PItA, але після того, як ви це зробите, ви отримуєте більшу частину потужності DVCS за допомогою наявного CVCS.}

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

Але насправді я фактично не відійшов від Субверсії. Я просто використовую git як мій локальний клієнт svn.