SVN, як вирішити нові конфлікти дерева, коли файл додається до двох гілок


95

При об’єднанні декількох гілок (за допомогою SVN 1.6.1), де до обох гілок був доданий файл (а потім працював у цих окремих гілках), я отримую один із нових конфліктів дерева:

      C foo.txt
  >   local obstruction, incoming add upon merge

Мені потрібні зміни з обох гілок, але конфлікт дерева не дає мені звичних файлів .working, .merge-left та .merge-right - це зрозуміло через природу конфлікту. Існує чимало таких конфліктів, і таких, коли в кожній гілці сталося видалення одного і того ж файлу, але їх легко вирішити.

Як я можу вирішити цю проблему? Книга SVN Redbean (для 1.6) не висвітлює цю ситуацію.

Відповіді:


40

Як згадувалося в попередній версії (2009) проекту "Конфлікт дерева" :

Конфлікт XFAIL із злиття файлу над версією

Цей тест робить злиття, яке додає додавання файлу без історії до існуючого файлу версій .
Це повинен бути конфлікт дерева у файлі local obstruction, incoming add upon mergeсорту ' '. Виправлені очікування в r35341.

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

Теоретичне рішення полягає в об'єднанні цих файлів вручну (із зовнішнім інструментом розрізнення) у цільовій гілці ' B2'.

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


2
Документ дизайну "конфлікту дерева" згнив :(
whitey04

4
Найцікавіше, що навіть якщо обидва додані файли ідентичні, вони все одно відображаються як суперечливі. Це насправді не слід позначати як конфлікт.
SantiBailors

1
@SantiBailors Так смішно, що я зараз вмираю. Вмираю за свого старого друга git ...
Зима

163

Я знайшов допис із пропозицією рішення цього . Він збирається запустити:

svn resolve --accept working <YourPath>

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


2
Дякую, це також вирішує: C foo.txt> локальне додавання, вхідне додавання після оновлення
lazysoundsystem

5
спасибі, це спрацювало і для мене, але мені довелося зробити це: svn резолюція --прийняти робочу
ІМЯ

5
так, вам потрібно ім'я файлу. Він приймає '.' (поточний каталог). Мені також потрібно було зробити це рекурсивно, щоб: "svn resolution --apcept working --recursive." вирішує все на користь вашої робочої копії (небезпечно! Ви можете дути чужі зміни, коли робите це, як завжди при вирішенні конфліктів)
Гаррі Вуд,

Я використовую псевдонім, який я створив, щоб перерахувати всі файли, що конфліктують з деревами: alias mtc='stat | awk "BEGIN { FS=\" \" } /^.{6}C/ { print \$NF }"' Тоді я можу використовувати це як аргумент до команди resol, наприклад: svn resolve --accept working $(mtc)
Граф Дженкінс

1
Насправді вам потрібно вказати також ресурс, наприклад: svn resolve --accept working path/index.html
Томаш Кутер

9

Що робити, якщо вхідні зміни - це ті, які ви хочете? Я не можу запустити вирішення svn --accept theirs-full

svn вирішити --прийняти базу


4
Думаю, я неправильно зрозумів питання. "base" справді еквівалентно "their-full" при використанні "svn resolution", але це не вирішує вашу проблему. Замість цього я розділив його на дві частини: 1) Видалити мій локальний конфліктний каталог (або файл), 2) Об’єднати. Це повинно виконуватися без конфліктів, і оскільки `` вхідні зміни - це ті, які ви хочете '', мені було б байдуже про видалені елементи
Gabriel FT Gomes

3

Мені просто вдалося вклинитися досить ретельно, намагаючись слідувати порадам користувача 619330 вище. Ситуація склалася так: (1): я додав кілька файлів під час роботи над моєю початковою гілкою, branch1; (2) Я створив нову гілку, галузь2 для подальшого розвитку, відгалуживши її від стовбура, а потім об’єднавши свої зміни з галуззю1 (3) Співавтор скопіював мої моди з гілки1 у свою власну гілку, додав додаткові моди, а потім злилися назад до багажника; (4) Тепер я хотів об’єднати останні зміни з транка в мою поточну робочу гілку, branch2. Це зі svn 1.6.17.

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

Ну, ні. Оновлення чергової копії гілки2 призвело до старої версії файлів (попереднє злиття магістралі). Отже, зараз у мене є дві різні робочі копії гілки2, нібито оновлені до тієї ж версії, з двома різними версіями файлів, і обидві наполягають на тому, що вони повністю оновлені! Перевірка чистої копії гілки2 призвела до старої (попередньої) версії файлів. Я вручну оновлюю їх до версії магістралі та фіксую зміни, повертаюся до своєї першої робочої копії (з якої я спочатку подавав зміни магістралі), намагаюся її оновити, і тепер отримую помилку контрольної суми для відповідних файлів. Здуйте відповідний каталог, отримайте нову версію за допомогою оновлення, і нарешті, я маю хорошу версію branch2 із змінами магістралі. Я сподіваюсь. Розробник попередження.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.