Чому я отримую конфлікти дерев у Subversion?

У мене була особливість гілки мого стовбура і періодично зливала зміни зі свого стовбура в мою гілку, і все працювало нормально. Сьогодні я пішов об'єднати гілку назад в стовбур і всі файли, які були додані до мого стовбура після створення моєї гілки, були позначені як "конфлікт з деревами". Чи є спосіб уникнути цього в майбутньому?

Я не думаю, що вони належним чином позначені.

Я знайшов рішення, читаючи посилання, яке дав Гарі (і пропоную йти цим шляхом).

Підводячи підсумки для вирішення конфлікту дерева, здійснюючи робочий каталог з клієнтом SVN 1.6.x, ви можете використовувати:

svn resolve --accept working -R .

де .конфліктний каталог.

ПОПЕРЕДЖЕННЯ : "Здійснення робочого каталогу" означає, що ваша пісочна структура буде тією, яку ви здійснюєте, тому, якщо, наприклад, ви видалили якийсь файл зі своєї пісочниці, він також буде видалений із сховища. Це стосується лише конфліктуючого каталогу.

Таким чином, ми пропонуємо SVN вирішити конфлікт ( --resolve), прийнявши робочу копію всередині вашої пісочниці ( --accept working), рекурсивно ( -R), починаючи з поточного каталогу ( .).

У TortoiseSVN, вибравши "Розв'язано" правою кнопкою миші, фактично вирішує цю проблему.

Subversion 1.6 додав конфлікти дерев для покриття конфліктів на рівні каталогу. Хорошим прикладом може бути, коли ви локально видаляєте файл, тоді оновлення намагається зменшити зміну тексту на цьому файлі. Інша справа, коли у вас є субверсія Перейменування файлу, який ви редагуєте, оскільки це дія "Додати / видалити".

У блозі Subversion від CollabNet є чудова стаття про конфлікти дерев .

З мого досвіду, SVN створює конфлікт із дерева, коли я видаляю папку. Здається, немає причин.

Я єдиний, хто працює над своїм кодом -> видалити каталог -> зробити -> конфлікт!

Я не можу дочекатися переходу на Git .

Слід уточнити - я використовую Subclipse . Ось, мабуть, проблема! Знову я не можу дочекатися переходу ...

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

Приклад:

Об'єднання / svn / Проект / гілки / деяка галузь / Джерела до / svn / Проект / стовбур ---> Конфлікт з дерева

Об'єднання / svn / Проект / гілки / деяка гілка до / svn / Проект / магістраль ---> ОК

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

Тут відбувається таке: Ви створюєте новий файл на своєму стовбурі, потім об'єднуєте його у свою гілку. У комісії злиття цей файл буде створений і у вашій філії.

Коли ви об’єднуєте свою гілку назад у стовбур, SVN намагається повторити те саме: Він бачить, що файл був створений у вашій гілці, і намагається створити його у вашому стовбурі під час злиття, але він уже існує! Це створює конфлікт з деревом.

Спосіб уникнути цього - зробити спеціальне злиття, реінтеграцію . Ви можете досягти цього за допомогою --reintegrateперемикача.

Про це можна прочитати в документації: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

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

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

Це теж є спосіб, але я ніколи цього не пробував. Ви можете прочитати його в цій публікації: Реінтеграція гілки субверсії в v1.6

Це може бути спричинено тим, що не використовуйте клієнтів однієї версії впродовж усього.

Використання клієнта версії 1.5 та клієнта версії 1.6 до одного сховища може створити подібні проблеми. (Мене просто вкусили.)

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

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

Це може статися на 1.4 сховищах, я не впевнений, чи допомагає тут інтегрований трек, що вводиться в 1.5.

До сьогодні, щонайменше 3 місяці тому, я регулярно стикався з сотнями конфліктів дерев при спробі об'єднати гілку назад у стовбур (використовуючи TortoiseSVN 1.11 ). Будь то на основі базування чи ні, BTW. Я використовую TortoiseSVN з його версії 1, ще в 2004 році, і я постійно реінтегрував гілки. Щось, мабуть, трапилося нещодавно?

Тому сьогодні я провів цей простий експеримент, і я виявив, що створює ці шалені конфлікти:

1. Я роздвоював багажник @ 393;
2. Я модифікував десятки файлів випадковим чином, а також створював нові;
3. Я вчинив. Зараз @ 395 (колега відправив у 394, щоб виконувати свої речі).
4. Тоді я спробував реінтегрувати гілку назад у стовбур, лише перевірити; дотримуючись рекомендації TortoiseSVN у майстрі: "щоб об'єднати всі зміни (реінтегрувати), залиште це поле порожнім". Щоб досягти цього, я клацнув правою кнопкою миші на папку магістралі і вибрав "TortoiseSVN> Злиття, з / шлях / до / гілки", і я залишив діапазон оборотів порожнім , як радили в діалоговому вікні.

Обговорення: (див. Додаток)

всі ревізії ... що? Мало що я знав, що клієнт, мабуть, мав на увазі " всі ревізії цілі! (Ствола)", оскільки під час реінтеграції цієї гілки я бачив згадку "Об'єднання ревізій 1-HEAD"! О БОЖЕ МІЙ. Бідний диявол, ти тут загинеш. Ця гілка народилася @ 393, ви не можете прочитати її свідоцтво про народження, заради Бога?

Роздільна здатність:

1. Всупереч тому, що радить майстер, вкажіть діапазон, який охоплює ВСІ перегляди ... життя філії! отже, 394-HEAD ;
2. тепер запустіть тест на злиття ще раз і отримайте сигару. ( ).

Мораль: Я не можу зрозуміти, чому вони досі не виправили цю помилку, тому що це одна, пробачте. Я мушу витратити час, щоб повідомити про це з ними.

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

Я вирішив проблему, перемістивши файл назад, зробивши, а потім об'єднавши свою гілку. Потім я перемістив файл назад. :) Це, здавалося, зробило трюк.

У мене була схожа проблема. Єдине, що насправді працювало для мене, - це видалити конфліктні підкаталоги за допомогою:

svn delete --force ./SUB_DIR_NAME

Потім скопіюйте їх знову з іншого кореневого каталогу в робочій копії, в якій є:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Тоді робіть

svn cleanup

і

svn add *

Ви можете отримати попередження з останнім, але просто ігноруйте їх і нарешті

svn ci .

У мене була ця сама проблема, і я вирішив її, повторивши злиття, використовуючи ці інструкції . В основному, він використовує "2-URL-злиття" SVN для оновлення trunkдо поточного стану вашої філії, не турбуючи стільки про історію та конфлікти дерев. Врятувало мене від ручного виправлення 114 конфліктів дерев.

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

Сценарій, до якого я іноді стикаюся:

Припустимо, у вас є магістраль, з якої ви створили відділення випуску. Після деяких змін на магістралі (зокрема, створення каталогу "some-dir"), ви створюєте функцію / виправити гілку, яку ви хочете пізніше об'єднати і у гілку випуску (оскільки зміни були досить малі, а функція / виправлення важлива для випуску) .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Якщо ви спробуєте об'єднати гілку функції / виправити безпосередньо у гілку випуску, ви отримаєте конфлікт із деревами (навіть якщо каталог навіть не існував у гілці функції / виправлення):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Тому вам потрібно явно об'єднати коміти, які були зроблені на магістралі, перш ніж створити функцію / виправити гілку, яка створила каталог "some-dir" перед об'єднанням гілки функції / fix.

Я часто забуваю, що як не потрібно в git.