Практика контролю версій для Rewrites

Ми розробили продукт (прототип) P_OLD мовою X і тепер переписуємо його з нуля як P_NEW мовою Y.

Оскільки P_NEW та P_OLD - той самий продукт:

Чи повинен P_NEW просто бути браком із P_OLD старого або це власне сховище?

Який звичайний спосіб впоратися з такими великими змінами з точки зору контролю версій?

Ви майже напевно хочете нового сховища.

Мета сховища:

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

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

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

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

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

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

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