Что может привести к слиянию SVN Update неправильно?

Несколько дней назад я получил электронное письмо от человека, у которого были проблемы с созданием проекта Delphi, который у меня есть в Google Code. Файл проекта и один из файлов DFM были закопаны после того, как он обновился с некоторыми изменениями, которые я зарегистрировал. Мы немного поговорили и проследили до того, что он сказал, что SVN добавляет дополнительные вещи. Он удалил файлы и снова запустил Update, и все заработало нормально.

Я никогда не видел эту проблему раньше, и я не мог воспроизвести или проверить какую-либо из них на моем конце. Не было никаких конфликтов обновлений с другими пользователями, так как я единственный, у кого есть доступ для записи в хранилище. Поэтому мне интересно, что могло вызвать это. Это известная проблема для SVN? Есть ли способ предотвратить это?

13.10.2009 00:10:47
6 ОТВЕТОВ
РЕШЕНИЕ

Если файл DFM был обработан Subversion как текст, предполагая, что у пользователя были локальные изменения, он попытается выполнить слияние. Там, где есть конфликты и Subversion не может их разрешить, он добавит дополнительную информацию, чтобы помочь вам вручную разрешить конфликты, вы увидите текст, <<<<<<< .mineкоторый, конечно, будет работать в Delphi. Также возможно, что Subversion автоматически произвела слияние, которое не конфликтовало, а приводило к повреждению файла DFM.

Причина, по которой вы не увидели проблему, вероятно, заключалась в том, что у вас не было локальных изменений, поэтому объединение не требовалось. При удалении или возврате файлов рабочая копия возвращается на BASE, поэтому при любом обновлении не требуется выполнять слияние.

Одно из решений: если у вас есть текстовые файлы, которые не следует объединять с помощью Subversion, установите для svn: mime-type подходящее нетекстовое значение, и оно будет обрабатываться как двоичное и не будет пытаться выполнить слияние. Вам нужно будет вручную решить проблему. Кстати, это также хороший совет, если вам нужно хранить конфиденциальные текстовые файлы в Subversion и не хотите, чтобы diff отображал содержимое :)

5
13.10.2009 08:17:03
Интересный трюк. Но тогда я утратил бы возможность использовать TortoiseSVN для проверки своих изменений, прежде чем регистрировать новый пакет кода.
Mason Wheeler 13.10.2009 04:13:36
Было бы легко испортить файл DFM, если объединение, изменение «неважных» деталей может привести к изменению порядка компонентов. Наивное слияние могло тогда полностью испортить это.
Gerry Coll 13.10.2009 04:27:46
@ Мейсон - ты пробовал? TortoiseSVN -> Diff покажет изменения (это было хорошо для меня, но я настроил его на использование Beyond Compare) SVN не будет показывать diff (скажем, в сообщении после фиксации), вместо этого он сообщит: «Двоичные файлы отличаются» , Прошло много лет с тех пор, как я написал в Delphi, но я предполагаю, что он аналогичен файлам дизайнеров .NET. Лично я не беспокоюсь об установке MIME-типа для такого типа файлов (я просто предлагал одно из возможных решений), потому что, если я вижу статус «Объединенный» после обновления автоматически сгенерированного и поддерживаемого файла, это довольно большая подсказка может пойти не так :)
si618 13.10.2009 05:49:19
Если неясно: я не предлагаю устанавливать svn: mime-type в качестве функции безопасности, но, учитывая, что большинство инструментов (которые отправляют подробности об изменениях в файлах) используют svn или svnlook, это способ предотвратить непреднамеренную защиту конфиденциальных данных. отправлено, что вы не ожидаете этого. Например, мы устанавливаем версии наших файлов svnserve authz и passwd, и, хотя у меня есть настройка authz в самом каталоге config, я не хочу, чтобы наш хук электронной почты после фиксации отправлял по электронной почте разницу изменений. Конечно, любой, имеющий соответствующую авторизацию, может увидеть изменения.
si618 13.10.2009 05:57:28
Опять же, это не мера безопасности, просто попытка уменьшить утечку данных.
si618 13.10.2009 15:17:38

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

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

Entia non sunt multiplicanda .

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

3
13.10.2009 00:20:36
Хорошая точка зрения. За исключением того, что файлы проекта и файлы DFM (описания форм) управляются IDE. Они хранятся в текстовом формате, но вы обычно не редактируете их вручную, как обычный исходный код. Я никогда не слышал о том, чтобы среда IDE повредила файл DFM, а поврежденные файлы проекта иногда случаются, но не очень часто. Поэтому я нахожу это объяснение немного маловероятным.
Mason Wheeler 13.10.2009 00:26:00
Я с вами полностью согласен , но теперь мы должны учитывать ошибки публикации , иначе систематическую ошибку . Конечно, это маловероятно, но и конкурирующие объяснения. Мы сравниваем маловероятные сценарии с другими маловероятными сценариями, и, учитывая, что будет сообщаться только о коррупции, факт, что коррупция встречается редко, может быть опасным фактором для аргументации.
DigitalRoss 13.10.2009 00:38:09
Я согласен, что, скорее всего, он разграбил его на месте. «Дополнительный материал, добавленный svn», вполне может быть информацией о конфликте, которую svn добавит к версионному файлу в рабочей копии, когда идентифицирует локальный конфликт. Разрешение конфликта лишило бы «лишних вещей». Или действительно, просто удалив их и повторив попытку. ;-)
Conor Boyd 13.10.2009 00:40:55

Содержали ли «закопанные» файлы текст «мой» или «их»?

Если так, то он, вероятно, испортил свое разрешение конфликта и в конечном итоге непреднамеренно совершил их или мой рев.

Или вполне возможно, что слияние решило, что может автоматически слить изменения, потому что они были в «несвязанных» частях файла, но для SVN (или любого наивного процесса автоматического слияния) «несвязанный» просто означает в строках файлов, которые т / не перекрывается.

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

1
13.10.2009 00:38:52

Какая версия Delphi? В старых версиях Delphi были ошибки, из-за которых иногда текстовые файлы DFM становились бинарными.

Файлы, внезапно становящиеся двоичными, уничтожают любую систему контроля версий

--jeroen

0
13.10.2009 14:45:02
2010, так что это не проблема здесь.
Mason Wheeler 13.10.2009 15:56:20
это все еще может быть: если SVN не поддерживает юникод должным образом (или один из клиентов SVN не поддерживает), то у вас будут проблемы
Jeroen Wiert Pluimers 13.10.2009 16:24:38

Вы работаете на нескольких платформах? Используете ли вы редакторы, которые принимают Unix-строки (как некоторые инструменты Cygwin?)

Если это так, проверьте, правильно ли вы настроили свойство eol-style.

0
13.10.2009 15:20:20

Я выполнял обновление SVN, а SVN копировал файлы DFM с моим <<<<<<<<. Mine, которого я никогда раньше не видел. Мне пришлось вручную удалить эти изменения, прежде чем Delphi позволит мне открыть проект.

0
16.10.2009 17:20:48