Робота з файлами – ЧАСТИНА 8

C-x v m (vc-merge)

Вливає зміни в робочий файл

Cx vm (vc-merge) бере набір змін і вливає їх у поточну версію робочого файлу Спочатку вона запитує у вас номер гілки або пару номерів версій в мінібуфер Потім вона знаходить відмінності від цієї гілки або між двома заданими версіями і обєднує їх в поточній версії поточного файлу

Як приклад припустимо, що ви завершили деякий додавання в гілці

131 Тим часом розробка стовбура просунулася до версії 15 Щоб влити зраді-

ня в стовбур, спочатку перейдіть в головний версію стовбура, набравши Cu Cx Cq RET Версія

15 тепер стала поточної Якщо для цього файлу використовується блокування, наберіть Cx

Cq для блокування версії 15, щоб ви могли її змінювати Потім наберіть C-x v m

131 RET Це візьме весь набір змін до гілки 131 (щодо версії 13, де гілка була розпочата, і до самої останньої версії цієї гілки) і вливає їх у поточну версію робочого файлу Тепер ви можете зафіксувати змінений файл, созадвая таким чином версію 16, яка містить зміни з гілки

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

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

Коли під час обєднання виникають конфлікти, VC помічає їх, говорить вам про них в луна-області і запитує, чи хочете ви допомогти в обєднанні Якщо ви відповідаєте так, VC запускає сеанс Ediff (див розділ Ediff в The Ediff Manual)

Якщо ви говорите немає, у файл вставляються обидва конфліктуючих зміни, оточені маркерами конфлікту Приклад нижче показує, як виглядають конфліктуючі області файл називається імя-файлу, а номер поточної версії у майстер-файлі, де знаходяться з зміни користувача Б – 111

<<<<<<< ім'я-файла

Версія користувача А

=======

Версія користувача Б

&gt&gt&gt&gt&gt&gt&gt  111

Тепер ви можете вирішити конфлікт, редагуючи файл вручну Або ви можете надрукувати Mx vc-resolve-conflicts після звернення до файлу Це запускає сеанс Ediff, як описано вище

14764  Мультиплеєрні розгалуження

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

Цей метод працює надійно і автоматично, за умови, що вихідні файли містять заголовки RCS про версії (див Розділ 14783 [Заголовки версії], с 128) Ці заголовки дозволяють Emacs завжди точно знати номер версії, присутсвии в робочому файлі

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

1477  Знімки

Знімок – це іменований набір версій файлів (одна для кожного зареєстрованого файлу), з якими ви можете звертатися як з одним цілим Один важливий вид знімка назвается випуском, це (теоретично) стабільна версія системи, готова до поширення серед користувачів

14771  Створення і використання знімків

Є дві основні команди для роботи зі знімками одна створює знімок із заданим імям, а друга витягує іменований знімок

C-x v s імя hRETi

Визначає останні збережені версії кожного зареєстрованого файлу в поточному каталозі або нижче нього як знімок із заданим імям (vc-createsnapshot)

C-x v r імя hRETi

Для всіх зареєстрованих файлів на рівні поточного каталогу або нижче вибирає версії, відповідні знімку із заданим імям (vc-retrievesnapshot)

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

Знімок займає дуже невеликий обсяг ресурсів – рівно стільки, скільки потрібно для запамятовування списку імен файлів і прінадлежіщіх знімку версій Тому потрібно не вагатися і створювати знімки завжди, коли вони можуть бути корисними

Ви можете надати в якості аргументу для Cx v = або Cx v ~ імя знімка (див Розділ 1474 [Старі версії], с 120) Таким чином, ви можете використовувати це для порівняння знімка з поточними файлами, або двох знімків один з одним або знімка із заданою версією

14772  Небезпечні місця при роботі зі знімками

Робота зі знімками в VC змодельована на основі поддежкі іменованих конфігурацій в RCS Для неї використовуються вбудовані засоби RCS, тому знімки, зроблені під VC з використанням RCS, видно, навіть коли ви обходьте VC

Для SCCS, VC реалізує знімки сама Використовувані їй файли містять трійки імя / файл / номер-версії Такі знімки видно тільки через VC

Знімок – це набір зафіксованих версій Тому при створенні знімка ви поса-

ни переконатися, що всі файли зафіксовані і неблокірованние

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

Якщо ви перейменовуєте зареєстрований файл, вам потрібно перейменувати і його майстер-файл (команда vc-rename-file робить це автоматично) Якщо ви користуєтеся SCCS, ви повинні також оновити записи про знімки, щоб вони посилалися на цей файл за новим імені (vc-rename-file робить і це теж) Старий знімок, який посилається на майстер-файл, який більше не існує під записаним імям, вже не коректний VC більше не може витягти його Достатня поглиблення в подробиці про RCS і SCCS для пояснення процесу ручного оновлення знімків вийшло б за рамки даного керівництва

Використання vc-rename-file зберігає коректність знімка для вилучення, але не вирішує всіх проблем Наприклад, деякі файли в програмі ймовірно посилаються на інші файли по іменах По самій меншій міру, перейменований вами файл згаданий в Make-файлі Якщо ви витягаєте старий знімок, перейменований файл отримує своє нове імя, а не те, яке очікує Make-файл Тому насправді програма не запрацює в тому вигляді, в якому її витягли

1478  Різні команди і можливості VC

Цей розділ розповідає про інші можливості VC, застосовуваних не настільки часто

14781  Журнали змін і VC

Якщо ви використовуєте для програми RCS або CVS і також супроводжуєте файл журналу її змін (див Розділ 2212 [Change Log], с 224), ви можете автоматично генерувати входження для нього з журнальних записів системи управління версіями:

Cx va Звертається до журнального файлу поточного каталогу і створює для зареєстрованих файлів у цьому каталозі нові входження для версій, зафіксованих пізніше останнього входження в цьому журнальному файлі (vc-updatechange-log)

Ця команда працює тільки з RCS або CVS, але не з SCCS

C-u C-x v a

M-1 C-x v a

Як вище, але знаходить входження тільки для файлу поточного буфера

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

Для прикладу припустимо, що перший рядок в ChangeLog датована 1999-04-10,

і що з тих пір сталося тільки фіксування, зроблене Натеніелом Боудича для

‘Rcs2log 1999-05-22 з журнальної записом Ignore log messages that start with # .’.

Тоді Cx va звертається до ChangeLog в вставляє подібний текст:

1999-05-22   Nathaniel Bowditch   &ltnat@apnorg&gt

* rcs2log: Ignore  log  messages  that start with  ‘#’

Тепер ви можете ще відредагувати нове входження в журнал за своїм бажанням

На жаль, мітки в файлах ChangeLog повідомляють тільки дати, тому деякі нові журнальні записи можуть продублювати те, що вже є в ChangeLog Вам доведеться видалити дублювання вручну

Зазвичай входження в журналі для файлу foo відображається як * foo: текст вхо

ждения . Знак : після foo опускається, якщо текст входження починається з рядка

‘(Імяфункції): . Наприклад, якщо входження для vcel таке: (vc-do-command): Check call-process status’, То текст в ChangeLog виглядає як:

1999-05-06   Nathaniel Bowditch   &ltnat@apnorg&gt

* vcel (vc-do-command):  Check call-process status

Коли Cx va додає кілька входжень одночасно, вона групує повязаний-

ві між собою журнальні записи разом, якщо всі вони зафіксовані одним автором

приблизно в один час Якщо входження для декількох таких файлів мають однаковий текст, вона обєднує їх в одне входження Наприклад, припустимо, що останні фіксування були з такими журнальними записами:

Для vctexinfo: Fix expansion typos’

Для vcel: Dont call expand-file-name’

Для vc-hooksel: Dont call expand-file-name’

В ChangeLog вони зявляться так:

1999-04-01   Nathaniel Bowditch   &ltnat@apnorg&gt

* vctexinfo:  Fix  expansion  typos

* vcel, vc-hooksel:  Don’t  call expand-file-name

Зазвичай Cx va розділяє журнальні записи порожнім рядком, але ви можете зробити так, щоб кілька повязаних записів зчіплювалися разом (без проміжної порожнього рядка), починаючи текст кожної з повязаних журнальних записів з мітки у формі

Джерело: Річард Столмен, Керівництво по GNU Emacs

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*