На щастя для тих із нас, хто все ще змушений використовувати CVS, git пропонує досить хороші інструменти для того, щоб робити саме те, що ви хочете зробити. Мої пропозиції (і що ми тут робимо на $ роботи):
Створення початкового клону
Використовуйте git cvsimportдля клонування історії ревізій CVS у сховище git. Я використовую таке виклик:
% git cvsimport -d $CVSROOT -C dir_to_create -r cvs -k \
-A /path/to/authors/file cvs_module_to_checkout
Цей -Aпараметр необов’язковий, але він допомагає зробити історію редагувань, імпортовану з CVS, більш схожою (див. man git-cvsimportДодаткову інформацію про те, як це налаштовано).
Залежно від розміру та історії сховища CVS, цей перший імпорт зайнять ДУЖЕ довго. Ви можете додати -v до вищевказаної команди, якщо ви хочете, щоб було спокійно, що щось насправді відбувається.
Після завершення цього процесу у вас з'явиться masterгілка, яка повинна відображати HEAD HEAD (за винятком того, що git cvsimportза замовчуванням ігнорує зобов’язання за останні 10 хвилин, щоб уникнути заповнення комісії, яка є напівзавершеною). Потім ви можете використовувати git logта друзів, щоб вивчити всю історію сховища так само, як ніби він використовував git з самого початку.
Налаштування конфігурації
Є кілька налаштувань конфігурації, які в майбутньому полегшать імпортний імпорт із CVS (а також експорт). Вони не задокументовані на сторінці git cvsimportman, тому я думаю, що вони можуть змінитися без попереднього повідомлення, але, FWIW:
% git config cvsimport.module cvs_module_to_checkout
% git config cvsimport.r cvs
% git config cvsimport.d $CVSROOT
Усі ці параметри можна вказати в командному рядку, щоб ви могли безпечно пропустити цей крок.
Зростання імпорту
Подальше git cvsimportмає бути набагато швидшим, ніж перше виклик. Однак це робиться cvs rlogу кожному каталозі (навіть у тих, у яких є лише файли Attic), тому це може зайняти кілька хвилин. Якщо ви вказали запропоновані конфігурації вище, все, що вам потрібно зробити, це виконати:
% git cvsimport
Якщо ви не налаштували ваші конфігурації для визначення за замовчуванням, вам потрібно буде вказати їх у командному рядку:
% git cvsimport -r cvs -d $CVSROOT cvs_module_to_checkout
У будь-якому випадку слід пам’ятати про дві речі:
- Переконайтеся, що ви знаходитесь у кореневому каталозі вашого сховища git. Якщо ви ще деінде, воно спробує зробити свіже,
cvsimportщо знову візьме назавжди.
- Переконайтеся, що ви перебуваєте у своєму
masterвідділенні, щоб зміни можна було об'єднати (або переоцінити) у ваші локальні / тематичні гілки.
Внесення місцевих змін
На практиці я рекомендую завжди вносити зміни до гілок і лише зливатися, masterколи ви готові експортувати ці зміни назад у сховище CVS. Ви можете використовувати будь-який робочий процес, який вам подобається у ваших гілках (злиття, повторне звільнення, розкручування тощо), але, звичайно, застосовуються стандартні правила перезавантаження: не перезавантажуйте, якщо хтось інший базував свої зміни на вашій гілці.
Експорт змін до CVS
git cvsexportcommitКоманда дозволяє експортувати одну фіксацію до сервера CVS. Ви можете вказати один ідентифікатор комісії (або що-небудь, що описує конкретну комісію, як визначено в man git-rev-parse). Потім генерується відмінність, застосовується до каси CVS, а потім (необов'язково) здійснюється до CVS за допомогою фактичного cvsклієнта. Ви можете експортувати кожну мікрокомісію у своїх галузях тем, але, як правило, мені подобається створювати поточну комісію для злиття masterта експортувати цю єдину комісію злиття в CVS. Коли ви експортуєте комісію злиття, ви повинні сказати git, який батьківський комітет комітету використовувати для створення розріз. Крім того, це не буде працювати, якщо ваше злиття було швидким вперед (див. Розділ "ЯК РОБОТИ РОБОТИ" man git-mergeдля опису швидкого злиття вперед), тому вам доведеться використовувати--no-ffваріант при здійсненні злиття. Ось приклад:
# on master
% git merge --no-ff --log -m "Optional commit message here" topic/branch/name
% git cvsexportcommit -w /path/to/cvs/checkout -u -p -c ORIG_HEAD HEAD
Ви можете побачити, що означає кожен із цих варіантів на сторінці man для git-cvsexportcommit . У вас є можливість встановити -wпараметр у вашому git config:
% git config cvsexportcommit.cvsdir /path/to/cvs/checkout
Якщо виправлення не вдасться з будь-якої причини, мій досвід полягає в тому, що вам, на жаль, буде краще скопіювати змінені файли вручну та здійснити використання клієнта cvs. Однак цього не повинно статися, якщо ви переконайтеся, що masterвін актуальний із CVS, перш ніж об’єднати галузь теми.
Якщо комісія не відповідає з будь-якої причини (проблеми з мережею / дозволами тощо), ви можете взяти команду, надруковану до вашого терміналу в кінці виходу помилки, і виконати її у вашій робочій директорії CVS. Зазвичай це виглядає приблизно так:
% cvs commit -F .msg file1 file2 file3 etc
Наступного разу, коли ви зробите git cvsimport(зачекавши не менше 10 хвилин), ви побачите, що патч вашої експортованої комісії повторно імпортується у ваше місцеве сховище. У них будуть різні ідентифікатори комісій, оскільки в CVS комісія буде інша часова марка та, можливо, інше ім'я виконавця (залежно від того, ви встановили авторський файл у своєму початковому cvsimportвище).
Клонування вашого клона CVS
Якщо у вас є кілька людей, які потребують цього cvsimport, було б ефективніше мати одне сховище git, яке виконує cvsimport, а всі інші сховища створені як клон. Це прекрасно працює, і клонований репозиторій може виконувати cvsexportкомісії так само, як описано вище. Однак є один застереження. Через те, як CVS здійснює повернення через різні ідентифікатори комісій (як описано вище), ви не хочете, щоб ваша клонована гілка відстежувала центральне сховище git. За замовчуванням так git cloneналаштовано ваш сховище, але це легко виправити:
% git clone [CENTRAL_REPO_HERE]
% cd [NEW_GIT_REPO_DIR_HERE]
% git config --unset branch.master.remote
% git config --unset branch.master.merge
Після видалення цих конфігурацій вам доведеться чітко сказати, з чого і з чого вийти, коли ви хочете зайняти нові коміти з центрального сховища:
% git pull origin master
В цілому, я вважаю, що цей робочий потік є досить керованим, і «наступна найкраща річ» при повністю міграції до git не є практичною.