Subversion mergeinfo испортилась после слияния транка с веткой - PullRequest
4 голосов
/ 20 июля 2011

Я тестирую последние версии Subversion, как клиента командной строки SVN, так и TortoiseSVN. (До этого момента я использовал в основном версии, предшествующие введению свойств mergeinfo и переключателя слияния --reintegrate.)

Я сделал обязательный поиск в Google, но у меня либо очень плохое Google-фу, либо то, что следует, на самом деле это проблема, которую никто не объяснил и / или полностью не решил. Я нахожу это несколько озадачивающим, поскольку здесь есть многочисленные сообщения о проблеме - нет проблем с поиском этих отчетов. Я также нахожу другие дискуссии о реквизитах mergeinfo, но ничего, что действительно соответствует и объясняет / решает то, что я испытываю.

Буду признателен за помощь в улучшении моего Google-фу или в понимании того, что происходит и что с этим делать.

Вот так:

  1. У меня есть транк (и рабочая копия BASEd на нем)

  2. Я создаю ветку (и рабочую копию BASEd на ней)

  3. Я делаю некоторые изменения в WC транка и фиксирую

  4. Я делаю некоторую работу в туалете филиала и фиксирую

  5. Теперь я объединяю работу в транке с туалетом моей ветви, разрешая любые конфликты.

Пока все идет так, как ожидалось, но когда я пытаюсь зафиксировать результат слияния, но я получаю сообщение о том, что рабочая копия устарела и ее нужно сначала обновить.

Это не имеет смысла. Унитаз был обновлен непосредственно перед слиянием, и целью слияния был WC. Так что в репо ничего не следовало менять.

Копая глубже, кажется, что проблема заключается в свойстве mergeinfo.

У меня нет проблем с передачей измененных файлов по отдельности, но после этого WC все еще грязный / не полностью зафиксирован, и я все еще не могу зафиксировать, потому что WC не обновлен. Таким образом, кажется, что Subversion касалась свойства mergeinfo как в репозитории, так и в WC.

В случае, если я повторяю это расследование, у меня нет проблем с тем, чтобы сначала обновить WC, а затем зафиксировать. Но я не уверен, что так будет всегда, иначе другие варианты этого явления будут сложнее решить. Я также не с нетерпением жду попыток «объяснить» это соседним пользователям Subversion, которые не считают это одним из своих «основных инструментов».

Я проверял это время от времени в течение нескольких лет, и я думаю, что эта проблема возникла с момента появления функциональности mergeinfo и --reintegrate (1.5?) До сих пор. Может ли это быть так? И это до сих пор не адресовано?

Мои текущие тесты были проведены как с клиентом командной строки (установленным из CollabNetSubversion-client-1.6.17-4.win32.exe), так и TortoiseSVN (TortoiseSVN-1.6.16.21511-win32-svn-1.6.17.msi ), и я получаю те же результаты.

Я использую Subversion уже много лет и описываю себя как «опытный пользователь». Тем не менее, с этой проблемой я стою со спущенными штанами ..

Добавление

Вот шаги, с помощью которых я могу воспроизвести проблему:

  1. Создайте репозиторий в "C: \ Documents and Settings \ johndoe \ My" Документы \ SVN \ Repo "

  2. С помощью браузера Repo создайте "file: /// C: / Documents and Настройки / johndoe / Мои документы / SVN / Repo / Trunk "(r1)

  3. С помощью браузера Repo создайте «file: /// C: / Documents and Settings / johndoe / Мои документы / SVN / Repo / Филиалы» (r2)

  4. Создать рабочую копию ствола в "C: \ Documents and Settings \ johndoe \ Мои документы \ SVN \ WCs \ Trunk" (без новой редакции)

  5. В транке создайте текстовый файл test.txt, добавьте его и подтвердите (r3)

  6. Создать ветку ствола в "file: /// C: / Documents and Settings / johndoe / Мои документы / SVN / Репо / Филиалы / Branch1" (r4)

  7. Создать рабочую копию этой ветви в "C: \ Documents and Settings \ johndoe \ Мои документы \ SVN \ WCs \ Branch1" (без новой редакции)

  8. В рабочей копии BASEd на Trunk добавьте строку текста в test.txt и зафиксируйте (r5)

  9. В рабочей копии BASEd на Branch1 добавьте строку текста для проверки.TXT и коммит (r6)

  10. Объединить ствол с веткой.Щелкните правой кнопкой мыши «C: \ Documents and Settings \ johndoe \ Мои документы \ SVN \ WCs \ Branch1», «Черепаха SVN», «Слияние».Тип слияния «Объединить диапазон ревизий», URL для слияния: «file: /// C: / Documents and Settings / johndoe / Мои документы / SVN / Repo / Trunk», Ревизии для слияния:, Рабочая копия: «C: \ Documents and Settings \ johndoe \ Мои документы \ SVN \ WCs \ Branch1 ", все остальное по умолчанию.В диалоге «Разрешить конфликт» «Разрешить все позже».(без новой редакции)

  11. Разрешить конфликт.Щелкните правой кнопкой мыши по файлу, SVN Tortoise, Edit Conflicts.В TortoiseMerge отметьте и выберите «Их до моих», нажмите «Пометить как решенные», сохраните и выйдите.(без новой редакции).

  12. Попробуйте зафиксировать изменения в Branch1.

В этот момент я получаю сообщение

Commit
C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1
Commit failed (details follow): 
Directory '/Branches/Branch1' is outof date 
You have to update your working copy first.

Это не имеет смысла для меня: до слияния рабочая копия была актуальной.После этого не было создано никаких новых ревизий (репозиторий HEAD по-прежнему r6), и теперь моя рабочая копия не актуальна.

Дальнейшее расследование похоже на Обновление WC для Branch1 какУже между шагами 9 и 10 проблема исчезнет.Опять же, это не имеет смысла для меня: i) В диалоге в конце обновления ничего не сообщается как фактически обновленное, и ii) Одна и единственная вещь, измененная в ветке, уже зафиксирована.Так что, на мой взгляд, WC является «чистым» (ничего незафиксированного) и современным (ничто в репо не может помочь WC).

Единственное, что на самом деле делает обновление, этоизмените BASE рабочей копии Branch1 с r4 на r6.Это как-то важно, но сейчас моя голова кружится слишком сильно, чтобы я мог пригвоздить детали.

Буду признателен за любые свежие мысли, которые заставят меня увидеть, что здесь происходит.

Приложение 2

Далее пытаюсь прояснить мое мышление: часто задаваемый вопрос гласит:

Когда Subversion фиксирует, клиент только увеличивает номера ревизии:узлы, к которым обращается коммит, а не все узлы в рабочей копии.Это означает, что в одной рабочей копии файлы и подкаталоги могут иметь разные ревизии, в зависимости от того, когда вы их в последний раз фиксировали.В некоторых операциях (например, при изменении свойств каталога), если в репозитории установлена ​​более поздняя версия узла, фиксация будет отклонена во избежание потери данных.

Я интерпретирую «узел»как «file: /// C: / Documents and Settings / johndoe / Мои документы / SVN / Repo / Branches / Branch1» в моем случае.На мой взгляд, в репозитории нет «более поздней версии [этого] узла».В целом, HEAD репозитория - r6, но самая последняя версия рассматриваемого узла - r4.

Ответы [ 3 ]

2 голосов
/ 20 июля 2011

Это не имеет ничего общего с реквизитом mergeinfo, но с тем фактом, что реквизит (хорошо, в данном случае свойство информации слияния) был изменен в папке .

См. FAQ запись об этом.

0 голосов
/ 27 июля 2011

После некоторых экспериментов ответ Стефана имеет немного больше смысла. Он абсолютно прав насчет того, что это не относится к свойству mergeinfo. Я подтвердил это, поместив свое собственное произвольное свойство в верхнюю папку моей рабочей копии ветви.

Мне все еще интересно узнать формулировку

В определенных операциях (например, при изменении свойств каталога), если в репозитории установлена ​​более поздняя версия узла, фиксация будет отклонено, чтобы предотвратить потерю данных. Начиная с момента ветвления (ветка выдала r4) I

  • Создайте WC этой ветви (и верхний каталог, и единственный файл в этом каталоге являются актуальными и чистыми (без внесенных изменений) на данный момент.
  • редактировать файл и фиксировать (HEAD - r5, COMMITTED для каталога - r4, зафиксировано для файла - r5)
  • Поместить свойство в каталог в WC

И снова, когда я пытаюсь зафиксировать, я получаю ошибку. Проблема с узлом папки.

SVN STAT дает:

C:\SVN T2\WCs\Branch1>svn stat
 M      .

DIFF показывает ровно одно изменение в папке (добавленное свойство):

C:\SVN T2\WCs\Branch1>svn diff

Property changes on: .
___________________________________________________________________
Added: je:dummy
   + Dummy value

Наконец, INFO говорит:

C:\SVN T2\WCs\Branch1>svn info
Path: .
URL: file:///C:/SVN%20T2/Repo/Branches/Branch1
Repository Root: file:///C:/SVN%20T2/Repo
Repository UUID: 009c3a97-e14f-234a-92e9-d30c537e29f9
Revision: 4
Node Kind: directory
Schedule: normal
Last Changed Author: SEEKDAHLJ
Last Changed Rev: 4
Last Changed Date: 2011-07-27 09:26:53 +0200 (on, 27 jul 2011)

Итак, моя БАЗА каталога - r4, HEAD - также r4, и у меня есть одно несвязанное изменение. Я не вижу, какой конфликт может быть.

Если кто-нибудь сможет пролить свет на это, я был бы очень рад. Чего мне не хватает?

Далее, выполняя аналогичную последовательность действий, но добавляя файл в каталог, а не добавляя свойство, такого конфликта не возникает.

Так что да, это связано, в частности, со свойствами, и Вопрос, который у меня остался, заключается в том, может ли кто-нибудь описать сценарий, в котором фактически возникает конфликт?

0 голосов
/ 21 июля 2011

Ты не одинок: я тоже это вижу. Похоже, что это не то, что вызывает проблемы, и, кажется, проявляет себя, когда вы пытаетесь зафиксировать свойства в папке, у которой есть дети от более поздней ревизии. Таким образом, в некотором смысле существует более поздняя версия вашего узла: версия из более поздней ревизии имеет дочерние узлы, отличные от версии из более ранней ревизии. Я не смотрел на код, но я представляю, что эти дочерние элементы хранятся на узле аналогично тому, как хранятся свойства.

...