Можно ли игнорировать изменения в svn: mergeinfo после слияния SVN?

Question

Я пытаюсь объединить одну фиксацию с ревизией 1000 (затрагивающей шесть файлов Java) из ствола в ветку. Выполнение следующих команд показали точно такой же эффект:

svn merge -c1000 https://<my-project>/trunk 
svn merge -r999:1000 https://<my-project>/trunk 

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

> svn diff SomeOtherFile.java 

Property changes on: SomeOtherFile.java 
___________________________________________________________________ 
Modified: svn:mergeinfo 
    Merged SomeOtherFile.java:r1000 

это нормально, чтобы вернуть все измененные svn:mergeinfo файлы и каталоги, и только совершают именно те шесть Java файлы, которые я изначально думал объединить? Каковы последствия?

Answer 1

Когда вы выполняете слияние в Subversion, вы должны почти всегда сливаться с базой проекта. Это верно, даже если цель слияния файла глубоко погружена в иерархию каталогов.

Subversion использует свойства (в частности, свойство svn:mergeinfo) для отслеживания слияния. Это свойство добавляется к базе, где происходит слияние. Если вы слились только из корня проекта, это свойство будет иметь только корень проекта. Если вы объедините все места, у вас будет svn:mergeinfo свойства, разбросанные по всему вашему проекту. В любое время происходит слияние, и есть свойство svn:mergeinfo где-то в этой иерархии каталогов, это свойство должно быть обновлено.

Не игнорируйте эти свойства, даже если указанные каталоги не изменены. В подкаталоге может быть файл, который зависит от этого svn:mergeinfo.

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

foo 
    src 
    test 
     ... 
    main 
     resources 
      ... 
     java 
      com 
       vegicorp 
        ... 
        munge 
         frapify 
          purèe.java 

на ветке, у вас есть изменение, которое включает в себя изменение purèe.java, которые вы хотите объединить в багажник. Легко войти в каталог foo/src/main/java/com/vegicorp/munge/frapify и обработать слияние оттуда. Это создает svn:merginfo в каталоге frapify, который будет с вами навсегда и всегда. Каждый раз, когда вы делаете слияние в любом родительском каталоге, вы получите изменение с этим svn:mergeinfo.

Вместо этого выполните слияние в корне проекта, каталог foo. Ваше слияние по-прежнему будет влиять только на файл purèe.java, но изменится svn:mergeinfo в каталоге foo, где все остальные слияния будут иметь место.

Таким образом, вы не можете игнорировать svn:mergeinfo. Самое лучшее, что произойдет, это то, что Subversion будет думать, что конкретная ревизия не была объединена, и снова сработает с этой ревизией. Хуже всего то, что вы испортили результаты слияния, и в итоге вы удвоите слияние.

Существует способ очистить этот беспорядок. Пройдите все свойства svn:mergeinfo в иерархии и убедитесь, что корень проекта имеет все эти изменения в информации о слиянии. Если нет, объедините эти изменения в корне. После того, как у вас есть корень svn:mergeinfo, содержащий каждое одно слияние, вы можете удалить другой svn:mergeinfo, рассеянный по всему проекту.

Однако, если вы не хотите, чтобы ваши разработчики выполняли свои слияния в корне проекта, вы просто закончите тем же беспорядком через несколько месяцев. Поэтому важно обучить своих разработчиков.

Разработчики - упрямые существа, которые настаивают на том, чтобы делать что-то по-своему. Мы использовали Maven на сайте, который имеет макет каталога по умолчанию, и одна команда настаивала на том, что они предпочитают собственный макет каталога. Это вызвало у нас всевозможные проблемы с проектом, но из-за махинаций этой команды произошел массовый отказ от развертывания, где им сказали либо сделать это так, как это делают все остальные (и как хочет это Maven), либо найти новую работу ,

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