Реінтеграція може бути використана лише в тому випадку, якщо версії 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.