Реінтеграція може бути використана лише в тому випадку, якщо версії X до Y були попередньо об'єднані з <URL> для реінтеграції джерела, але це не так


127

Використовували гілки SVN з черепахою 1.6. Я періодично з’єднував стовбур у гілці, щоб оновити його.

Сьогодні я думав, що реінтегрую галузь. Я вибрав "Reintegrate a branch" від Tortoise і отримав таке повідомлення про помилку:

Реінтеграція може бути використана лише в тому випадку, якщо версії 4709 - 5019 були попередньо об'єднані з http://subversion/svn/saxdev/trunkджерелом реінтеграції, але це не так

Потім він перелічив близько 50 файлів з описами, такими як цей:

Error: branches/qst/kobalt/sax/businessobjects/util/HistoryParent.java

Error: Missing ranges: /trunk/kobalt/sax/businessobjects/util/HistoryParent.java:4709-5018

Версія 5019 є головною редакцією. Перегляд 4737 був переглядом, коли я створив філію.

Я маю це з журналу для перегляду 4737

Дія: Доданий шлях: / гілки / qst Копіювати з шляху: / trunk

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

Будь-які ідеї?


1
Добре. Я насправді більше не використовую Subversion, але візьму за це ваше слово!
— colinjwebb

1
Дякую, чувак. Я думаю, що сторінка для цього краще.
— Сірий

Відповіді:


138

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

$ svn merge --reintegrate https://server.blah/source/orb/branches/bronze_services
svn: Reintegrate can only be used if revisions 650 through 694 were previously merged from
     https://server.blah/source/orb/trunk to the reintegrate source, but this is not the
     case:
  branches/bronze_services/occl
    Missing ranges: /trunk/occl:650-693

У Google я бачив ряд обхідних шляхів, але вони змусили мене нервувати як "хакі". Щоб вирішити це, я вирішив зробити саме те, на що натякає підрив у повідомленні. Я повернувся до своєї філії і явно об'єднав вказані зміни:

$ svn merge -r 650:693 https://server.blah/source/orb/trunk
$ svn commit -m 'merged revisions 650:693 from trunk'
    Sending        occl
Committed revision 695.

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

Я сподіваюся, що це допомагає


16
Приємно! "зробіть саме те, на що натякає підрив у повідомленні". :)
— Адам

7
Я згоден, більш популярна відповідь спокуслива, але, напевно, краще її правильно виправити. Мені довелося перейти до конкретного проблемного файлу і svn mergeце з магістралі.
— Стів Келет

1
Це спрацювало для мене чудово. Основна хитрість полягала в тому, що Черепаха не сказала мені перегляду проблеми. Після оновлення мого командного рядка клієнт svn я зміг дозволити йому надіслати мені повідомлення, як у вас, а потім зміг з’єднати версію проблеми та повернутися до магістралі.
— користувач12861

7
Це не спрацювало для мене, оскільки перелічені "відсутні" злиття вже були зроблені у відділенні (реінтегрувати джерело).
— Сем

6
Хоча ця відповідь звучить розумно, для мене це не спрацювало. Я постійно отримував ті ж повідомлення про помилки. Що допомогло, це було видалити властивості svn: mergeinfo із перелічених файлів, як і підходить відповідь.
— Дженні О'Рейлі

85

[[Хоча моє рішення раніше працювало для мене, воно може призвести до неправильних результатів із сучасними клієнтами SVN. У нашому випадку помилки злиття, здавалося, були побічними продуктами автоматики, які заплутали нашу історію SVN, а не реальну діяльність. Я залишаю це для нащадків, але, будь ласка, розгляньте прийняту відповідь. ]]

Для мене рішення було видалити будь-які svn:mergeinfoвластивості, які якимось чином приєднуються до окремих файлів в ієрархії.

svn merge --reintegrate svn+ssh://svn/usr/local/svn/repos/all/trunk 
svn: Reintegrate can only be used if revisions 18765 through 18921 were
    previously merged from svn+ssh://svn/usr/local/svn/repos/all/trunk to the
    reintegrate source, but this is not the case:
trunk/proj/src/main/java/com/foo/furniture.java
Missing ranges: /trunk/proj/src/main/java/com/foo/furniture.java:18765-18920

Щоб знайти файли з інформацією про об'єднання, ви можете зробити:

cd ~/svn/branches/2.7
svn propget -R svn:mergeinfo .

Тоді ви можете видалити властивості об'єднання інформації:

svn propdel svn:mergeinfo proj/src/main/java/com/foo/furniture.java ...
svn commit -m 'removed mergeinfo' proj/src/main/java/com/foo/furniture.java ...

Після того, як я це завершив, мій злиття виконав штраф.


2
Це дійсно допомогло мені вирішити свою проблему, але моє було пов’язане з об'єднанням ревізії з дочірньої папки, а це робиться в кореневій папці. Моя проблема полягала в тому, що я здійснив злиття, але коренева папка не визнала, що злиття відбулося, це означало, що мені довелося вручну оновити опору mergeinfo з відсутніми номерами версії. ПРИМІТКА. Я міг це зробити лише тому, що для редагування не було змін інших файлів, і це призведе до несподіваної поведінки, якщо інші файли потрібно об'єднати - вам потрібно буде знову об'єднати версії, якщо це так.
— ВиконанняЗамовник

5
У TortoiseSVN можна клацнути правою кнопкою миші файл, вибрати "TortoiseSVN" -> "Властивості" та видалити властивість svn: mergeinfo.
— StarCub

3
@StephenKennedy Можливо, ви зіткнулися з проблемою повторного використання гілки, яка вже була реінтегрована. Якщо так, перегляньте останній розділ svnbook.red-bean.com/en/1.7/…, починаючи з "Щойно - зробіть інтеграційне об'єднання від гілки до стовбура, гілка вже не придатна для подальшої роботи"
— AlexMA

6
+1. Вам не потрібно видаляти всі об'єднання інформації; лише ті, у яких відсутні діапазони. Дивіться мою відповідь про спосіб видалити лише проблему mergeinfos, фільтруючи висновок помилки TortoiseSVN.
— Ієн Самуель Маклін Старійшина

4
-1. Ви не повинні видаляти властивості об'єднати інформацію, якщо ви не впевнені в тому, що робите. Багато людей можуть прочитати це, видалити ці властивості та ненавмисно ввести інші проблеми. Пол Віпп має кращу відповідь.
— Bizmarck

15

Якщо ви спробуєте реінтегрувати свою гілку до магістралі, ви побачите подібні помилки від TortoiseSVN:

Тест реінтеграції злиття лише не вдався !: "Реінтеграція може бути використана лише у тому випадку, якщо деякі ревізії раніше були об'єднані з магістралі, але це не так"

Клацніть текст помилки та натисніть CTRL+ A, CTRL+, Cщоб скопіювати весь текст.

Вставте текст у рядок сюди цього сценарію PowerShell:

@"
Command: Reintegrate merge http://svn.cloudcorp.com/branches/myproject into C:\Users\iain\Documents\Repositories\CloudCorp\trunk  
Error: Reintegrate can only be used if revisions 18089 through 18612 were previously  
Error:  merged from http://svn.corp.skyscanner.local/svn/SkyScannerDatabase/trunk to  
Error:  the reintegrate source, but this is not the case:  
Error:    
Error:  branches/myproject/userdata/usermanagementservice  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/usermanagementservice:18365,18404  
Error:    
Error:  branches/myproject/userdata/auto_create_db.sql  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/auto_create_db.sql:18406  
Error:   
Error:    
Error:  branches/myproject/userdata/create_audit_tables_triggers_uds.sql  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/create_audit_tables_triggers_uds.sql:18406  
"@ -split "`n" |
? { $_ -match ('Error: +branches') } |
% { $_.Substring($_.IndexOf('userdata')) } |
% { "svn propdel svn:mergeinfo $_" }

Сценарій витягує відносні шляхи файлів із проблемою mergeinfo та виводить список команд для виправлення кожної з них.

Можливо, вам доведеться змінити 'userdata'значення відповідно до вашої структури сховища.

Виконайте сценарій для виведення команд, необхідних для видалення проблеми mergeinfos.

У цьому прикладі сценарій дасть такий результат:

svn propdel svn:mergeinfo userdata/usermanagementservice  
svn propdel svn:mergeinfo userdata/auto_create_db.sql  
svn propdel svn:mergeinfo userdata/create_audit_tables_triggers_uds.sql  

У командному рядку ви можете перейти до бази відділення (myproject) та виконати команди для видалення проблеми mergeinfos.

Ви повинні побачити такий результат:

property 'svn:mergeinfo' deleted from 'userdata\usermanagementservice'.
property 'svn:mergeinfo' deleted from 'userdata\auto_create_db.sql'.
property 'svn:mergeinfo' deleted from 'userdata\create_audit_tables_triggers_uds.sql'.

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


1
Задовго до реінтеграції я зробив (не реінтегрував) деякі зміни в стовбур з моєї гілки, тому що я випадково прихильнився до своєї гілки, коли мав намір здійснити ствол. Чи може це бути причиною цих реінтеграційних помилок?
— Ієн Самуель Маклін Старший

Саме це, мабуть, спричинило цю проблему в моєму випадку. Дякуємо, що знайшли час для написання сценарію!
— Сем

@Sam Рада, що Ви вважаєте це корисним. Вам потрібно було замінити буквальний простір на а, \s+щоб він працював для вас?
— Ієн Самуель Маклін Старший

Різновид; це було більше того, +що потрібно, щоб він працював на мене. У моєму випадку деякі рядки мали два пробіли, а інші - три, тому потрібна підтримка змінної кількості пробілів. Я не впевнений, чому я змінив простір на \s; що, напевно, не було необхідності, тож шкода цієї частини!
— Сем

@Sam Не хвилюйтесь, але я поверну його до прямого простору, поки TortoiseSVN не почне змішувати його з вкладками чи будь-яким іншим :-) Я покинув те, +як це було для вас корисним.
— Ієн Самуель Маклін Старійшина

11

Насправді я виправив це за допомогою параметра "об'єднати дві різні гілки", щоб об'єднати стовбур та гілку у свою робочу копію. Тоді я поклав це на багажник.

Чудовий


4
Ця відповідь насправді не пояснює, що ви зробили. Ні прикладів, ні посилання на необхідний розділ посібника.
— zigg

Заднім числом, ні, це не так. Однак, оскільки це була моя власна відповідь в той же день, що і питання, це була найкраща відповідь на кілька місяців. Хочеться припустити, що це має сенс, якщо ви все ще використовуєте Tortoise SVN 1.6. Зараз я прийняв відповідь Грея як прийняту відповідь.
— colinjwebb

Приклад: svn merge ^ / tags / wx ^ / tags / yz. Помилка повторної інтеграції виникла для мене під час використання 1.8 та злиття в магістраль, де джерело злиття провів певну ревізію, попередньо об'єднану в неї зі стовбура. 1.8, схоже, вирішили, що намагається здійснити повторне інтегрування, чого не було. Злиття з сухим виконанням з 1.6 спрацювало б добре, але два злиття URL-адрес також підходять.
— Нік

1
Точний сценарій, який не вдався до версії 1.8, - це копіювання тегу з деяких версій назад для випуску виправлення, вишневий вибір зміни із стовбура на задній репортаж шляхом злиття в патч-тег, внесення подальших змін до виправленого тегу та об'єднання цього списку назад в багажник. Зміни між базовим тегом та виправленою версією - це те, що потрібно об'єднати назад до магістралі, і злиття 2-х URL-адрес працює для цього.
— Нік

Я повинен був прочитати цю відповідь, перш ніж витратити 3 дні, намагаючись зрозуміти, що відбувається. Я досі не розумію, чому у мене виникла ця проблема, але підозрюю, що коментар від @Nick є причиною - і зараз все працює, я більше не буду шукати ...
— Дейв Річардсон,

6

Щось, що працювало для мене у черепашному SVN: замість того, щоб зливати всі редакції з гілки, виберіть певний діапазон і вручну виберіть усі свої версії з гілки.


1
Дякую за таку основну ідею. З усіх відповідей ця була не лише найменш складною, але була єдиною, яка працювала на мене.
— redman

3

Робіть так, як вам каже SVN.

  1. З’єднайте гілку з Реверсією, про яку вам говорить SVN
  2. Реінтегруйтесь із відділення в стовбур

2
Не працювало для мене. Зміни вже існували у галузі. Ваші вказівки виглядають так, що вони повинні працювати в деяких випадках, але вони, здається, базуються на припущенні, тому вони не здаються універсальними.
— Сем

1

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


0

Я зіткнувся з цим питанням. Я зробив журнал SVN на своїй гілці, щоб знайти, чи приєднав я стовбур до своєї гілки.

Я зазначив усі доопрацювання.

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

Мені довелося зробити кілька ревертів на mergeinfo, але я зв'язав свій код.

Я негайно видалив своє відділення.


0

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


0

Початок цього питання

  • TortoiseSVN 1.9.7, збірка 27907 - 64 біт, 2017/08/08 19:34:38
  • Subversion 1.9.7, -випуск
  • apr 1.5.2
  • apr-util 1.5.4
  • кріпак 1.3.9
  • OpenSSL 1.0.2l 25 травня 2017 року
  • zlib 1.2.8
  • SQLite 3.14.1

клацніть правою кнопкою миші на гілку, де ви хочете об'єднатись (але отримуючи це повідомлення) та оберіть опцію "оновити до редакції", а потім у діалоговому вікні, яке відкриється (знімок екрана), виберіть ці версії та натисніть кнопку ОК - як тільки всі попередні редакції об'єднані, Ви б не отримали це повідомлення

введіть тут опис зображення

Додайте це сюди, щоб допомогти тому, хто використовує Tortoise SVN


-1

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

Я клацнув правою кнопкою миші на проблемних файлах: TortoiseSVN> Властивості, і виявив, що у файлу два svn: mergeinfo, і один з них не успадкував дані. Тож я видалив цю об'єднану інформацію.

Я використовую TortoiseSVN 1.12.2, Build 28653 - 64 біт.

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