Використання SVN погано - це Mercurial відповідь?

На роботі ми використовуємо SVN, але тільки в імені. Ми не відділяємось та не об’єднуємось. Ми зберігаємо дві копії сховища, одна служить гілкою "тегів", яка копіюється під час розгортання та зберігається для виправлень помилок та негайних "функцій типу" це має перейти в реальному часі ". Ми маємо пам’ятати, щоб скопіювати зміни, внесені в одній копії, до іншої копії («магістраль»). У нас є десяток проектів всередині однієї папки в сховищі, а не розділяти їх. Коротше кажучи, про єдине, для чого ми використовуємо SVN - це можливість здійснювати. Все інше робиться вручну.

Я оцінював Меркуріал; Раніше я використовував Git (я єдиний в команді, який використовував DVCS), і я швидко збираю Mercurial. Я обговорюю питання про те, щоб представити Mercurial іншій команді як "кращий спосіб" робити справи, тому що розгалуження - це швидко, злиття набагато простіше, і ми можемо зафіксувати речі локально за змістом серця і лише підштовхнути їх до центральної гілка, коли вони будуть готові. Ми отримаємо всі переваги SVN (і ми так і не отримаємо багато переваг зараз, оскільки ніхто не розуміє SVN), а також для нових функцій нам не доведеться плавати тонни неперевершених файлів, тому якщо нам доведеться відкатати. ми накручені. Робочий процес здається дещо простішим - нам просто потрібно пам’ятати, що «Виконати» є локальним, а «Нажати» - це так, як SVN,

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

Так.

Якщо ви заміните "SVN" на "Perforce" у вашій ОП, ви майже отримали ситуацію, в якій я опинився, коли я розпочав свою поточну роботу, навіть до копіювання вручну. Два роки ми на Mercurial, і всі згодні, що це було великою зміною.

У нас є можливість розгалуження та об'єднання за кожним випадком підтримки , що неймовірно корисно для QA, а також можливість створювати будь-яку кількість викидних гілок та сховищ, коли нам здається, що ми можемо потім створити та перевірити на нашому сервері CI, а потім розгорнути до хмарного тестового середовища та перевірити функціональність. Це принесло величезну користь з точки зору душевного спокою, коли ми робимо реалізацію в реальному часі, ми майже на 100% впевнені, що вона спрацює (без проблем щодо оточення / БД, які, очевидно, виходять із сфери використання VCS).

В основному, те, що ми отримали від переходу на меркуріал, - це дихальний простір. Нам більше не доведеться турбуватися про вартість відділення, або про жахливі сеанси злиття, які неминуче використовувались для наслідування, все набагато простіше. Ми також дуже активно використовуємо FogBugz, тому прив'язка до Kiln (їх розміщений mercurial) дуже корисна.

Коментар щодо сайту hginit також є чітким , як контур для робочого процесу контролю версій, який насправді працює (припускаючи, що ви налаштуєте його під конкретний робочий процес QA вашої компанії).

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

Я не згоден з коментарями щодо розміру команди та розподілу команди, що стосується того, чи потрібно використовувати DCVS. Дійсно, мова йде про розподіл CODE. Якщо у вас паралельно відбувається декілька циклів розвитку, або випадки підтримки в застарілій системі, або купа функцій, або навіть нові системи (що за звуком цього ви робите), ви отримаєте користь від використання DVCS.

Інший інструмент, ймовірно, не вирішить вашу проблему, я б сказав, що ви повинні прочитати цю статтю, і я вважаю це найбільш корисним:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Я вважаю, що головний пункт статті підсумований тут, але будь ласка, прочитайте його:

Зрештою: не дуже про інструменти

За весь час, який я проводив, працюючи та інтегруючи різні системи управління джерелами, я прийшов до одного висновку: це не інструмент, а те, як ви ним користуєтеся. Це страшенно зламане твердження, але це здається особливо вірним. При правильному управлінні змінами вихідного коду - маркування для збірок, розгалуження за винятком тощо - навіть найпізніша система управління джерелом (* кашель * SourceSafe * кашель *) набагато перевершить налаштування Меркуріалу з купою випадкових зобов'язань і штовхає.

Ні. Технологія рідко вирішує подібну проблему.

Меркуріал складніший за Subversion (так, розгалуження та злиття - це краще, а можливо, і простіше, але модель Subversion значно простіша, ніж Mercurial). Якщо ви використовуєте Subversion таким чином, що може спричинити мозковий потік, ви можете використати Mercurial:

• а) Адекватно чи краще
• b) Недостатньо, але краще, ніж ваше поточне використання Subversion
• в) Так само неадекватно, як зараз
• г) гірше, ніж зараз

в) і г) звучать як найбільш ймовірні результати. Запишіть, чому ви думаєте, що закінчитесь в а) чи б).

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

Ні. Інструменти не замінюють методологію.

Якщо ви не використовуєте Subversion як SCM , ви також не можете використовувати Mercurial (і це станеться, швидше за все)

SVN може робити все, що вам потрібно, і немає необхідності міняти коней середнім потоком для сумнівної виплати.

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

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

1. Приведіть «тренера», щоб забезпечити серію практикумів для команди. Це, мабуть, має бути зовнішньою людиною (за іронією долі, багатьом командам часто легше довіряти стороннім, ніж довіряти комусь із команди). Це повинен бути хтось, хто знає її речі зсередини, і який може ефективно навчити людей цим навичкам на всіх рівнях розуміння та розробити прагматичний план для впровадження нового VCS (*) на робочий процес команди.

2. Почніть проект "скункс-роботи", щоб тестувати драйв та перевірити новий VCS на невеликому бічному проекті. Виберіть пару розробників "альфа", які бажають спробувати нові речі і не проти зібрати купу невдалих експериментів. Коли роботи з скунсом здатні продемонструвати БЕЗКОШТОВНІ поліпшення в робочому процесі, тоді ви можете спробувати запустити його до решти команди, і у вас є пара євангелістів, які допоможуть вам це зробити.

(*) "новий VCS" Я не обов'язково маю на увазі меркурій або git, це також може бути SVN (зроблено правильно).