Метод інтеграції різних систем управління версіями або вибору однієї з інших, завдяки злиттям та поглинанням?

11

Компанії набувають інших компаній, які використовують різні системи управління версіями.

Чи є загальна думка щодо того, як інтегрувати такі системи разом, наприклад, використовуючи мост Subverson-GIT або навіть прийняти рішення про використання лише одного інструмента над іншим - і як мігрувати між системами?

Чи використовують люди набір критеріїв для такого прийняття рішень, наприклад, еквівалент тесту "Joel" на розробку програмного забезпечення?

version-control migration

— therobyouknow
джерело

11

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

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

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

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

Файли / проекти, які були стабільними до міграції (повинні бути рівними) залишаються стабільними після міграції, тому вам не потрібно буде посилатися на історію. Ми виявили, що якби нам довелося досліджувати помилку в такому старому файлі / проекті, що має історію, це насправді не принесло користі. Поки ви зберігаєте старе сховище 6 місяців на рік, ви матимете довідку в таких випадках.

— ChrisF
джерело

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

— therobyouknow

1

+1 ІМО - найкраща стратегія. Продовжуйте використовувати лише один, інші в режимі лише для читання на всякий випадок.

— користувач281377

1

+1: більш точна відповідь на міграційну частину.

— VonC

1

+1 - досить важко зрозуміти існуючий код, не кажучи вже про три останні версії.

— JeffO

1

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

— JBRWilkinson

4

Що стосується управлінської сторони, то головним чином питання:

підтримка : чи компанія, яка випускає VCS, все ж буде там у разі проблем.
Це, на жаль, одна з головних причин, чому такі застарілі продукти, як ClearCase, як і раніше вважаються (ClearCase з 2003 року ... продукт IBM )
вартість ліцензії : навіть якщо є безкоштовні альтернативи, іноді "групові ліцензії" для VCS можуть бути узгоджені або фактично включені в набагато більший контракт, включаючи сервери, мережі, підтримку тощо ... Глобальна ліцензія на такий продукт може закінчитися дорожче коштує набагато менше, ніж державна ціна.

Що стосується проекту, це також питання:

адміністрування : на якому сервері ви встановите VCS (або багато VCS, якщо ми говоримо про Git, SVN та інші)? З якою політикою резервного копіювання? Який DRP (план відновлення Disastry)?
місцева підтримка : хто візьме підтримку першого рівня? рівень 2?
Знання ринку : Ви впевнені, що знайдете достатньо розробників та / або адміністраторів з відповідним набором знань, щоб використовувати цей VCS та всі його функції?

Безкоштовно чи ні, пам’ятайте, що «безкоштовне» програмне забезпечення є безкоштовним, як у «вільній мові» (ви можете вибирати та розгортати потрібне), а не як «безкоштовне пиво» (це все одно коштуватиме багато грошей на сервері , резервне копіювання, адміністрування, підтримка, ...)

Згадані вище критерії - це початок для визначення, який ДКС зберігати, а що відмовитися.
Але в останньому випадку потрібно врахувати:

міграційна стратегія : чи можна експортувати / імпортувати історію проекту з однієї VCS в іншу?
мостова стратегія : чи є сенс мати історію у двох різних ДКС?
застарілість проекту : якщо проект знаходиться в стані технічного обслуговування / End Of Life, можливо, краще короткий час підтримати старий VCS.

— VonC
джерело

+1 хороша відповідь, куля вказує критерії, які я шукаю, і ваші пояснення з ними також допомагають. Я дам шанс іншим, перш ніж приймати відповідь. Дякую.

— therobyouknow

1

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

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

Редагувати

Я думаю, що я щось зрозумів, що малося на увазі в питанні та в інших відповідях. Справа в тому, що VCS також використовується для управління залежностями. Я знаю, що досить часто використовуються функції VCS, як svn:externalsінтегрувати одне репо (залежність) з іншим.

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

— баряк
джерело

Потреба в інтеграції різних систем? Так, якщо робота однієї команди використовується іншою командою. Інтеграція може бути тісною або втрачатися залежно від рівня необхідності та наявних ресурсів персоналу. Ні, якщо проекти повністю незалежні. Єдине, що залишається занепокоєнням - це підтримка більш ніж однієї системи і те, чи сприймається це добре чи погано. Добре, якщо ми приймаємо, що ми живемо у різноманітному обчислювальному світі чи погано, якщо думаємо, що нам слід зосередитись та виявити рішучість заради них самих, вибравши один інструмент, який може бути надто соліпсистичним!

— therobyouknow

PS. +1 Пощастило тобі, барак, за те, що ти в організації, яка терпить різноманітне обчислювальне середовище.

— therobyouknow

0

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

— JeffO
джерело

+1 Тут реалізм. Людям потрібно стримувати нерви, бути сміливими та продовжувати. Ризики потрібно чітко визначити. Одне навчання, яке я бачу і чую, як інші люди кажуть на своєму робочому місці, - це те, що іноді ми недостатньо працюємо над тим, щоб зменшити невизначеність / чітко визначити ризики / суперечності, перш ніж брати участь. Здавалося б, є достатньо часу для ітерації «помиліть / помиліть» / «виправте», але не вистачає часу, щоб вперше її виправити. Виправлення проблем винагороджується і сприймається як активна діяльність, навіть якщо іноді вони були непотрібними.

— therobyouknow

1

Це залежить від питання, про який йдеться, та того, наскільки добре проведена міграція. Перехід від Git або навіть CVS до будь-якого блокуючого VCS буде надзвичайно стримуючим.

— Девід Торнлі