разрешение SVN бинарных конфликтов

Question

Я использую SVN для проекта, над которым я работаю с несколькими другими разработчиками. Svn отлично работает для управления исходным кодом, однако мы все можем получить конфликты, когда мы фиксируем dll.

Когда я разрешаю конфликт (который удаляет мои dll, поскольку программа diff не может обрабатывать двоичные файлы), тогда приходится перестраивать для фиксации. Как вы собираетесь разрешать подобные конфликты?

Edit:

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

Answer 1

Если вы строите библиотеку DLL (а не внешнюю, для которой у вас нет источника), тогда источник должен находиться под контролем источника, а не в двоичном.

Если вы не хотите включать его в этот конкретный репозиторий, вы можете включить его как svn: external.

Answer 2

Как уже упоминалось в других ответах здесь: вы не должны сначала создавать версии сгенерированных dll. Но если у вас действительно есть для их версии, то вы можете разрешить конфликт, не используя утилиту diff, которая удаляет ваши dll-файлы:

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

filename.mine

Это ваш файл в том виде, в каком он существовал в вашей рабочей копии до того, как вы обновили свою рабочую копию, то есть без маркеров конфликта. Этот файл содержит только ваши последние изменения. (Если Subversion считает, что файл не подлежит объединению, файл .mine не создается, поскольку он будет идентичен рабочему файлу.)

filename.rOLDREV

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

filename.rNEWREV

Это файл, который ваш клиент Subversion только что получил от сервера, когда вы обновили свою рабочую копию. Этот файл соответствует версии HEAD хранилища.

Здесь OLDREV - номер редакции файла в вашем каталоге .svn, а NEWREV - номер редакции HEAD хранилища.

Теперь, чтобы разрешить такой конфликт, удалите ненужные файлы:

• если вы хотите сохранить свою собственную dll, удалите файлы filename.rOLDREV, filename.rNEWREV
• если вы хотите сохранить dll из хранилища, удалите файлы filename.rOLDREV и filename.mine, затем скопируйте filename.rNEWREV в имя файла

после этого выполнить

svn resolved filename

, чтобы сообщить Subversion, что вы решили конфликт самостоятельно.

Answer 3

Как правило, вы вообще не будете хранить свои собственные скомпилированные библиотеки DLL в управлении исходным кодом. У вас есть конкретная причина, по которой вам нужно это сделать?

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

• Избегает конфликтов двоичных файлов при попытке проверить в DLL или EXE
• Объем данных, отслеживаемых вашей системой управления источниками, значительно меньше, что делает его быстрее
• Когда разработчики всегда создают свои собственные библиотеки DLL, они могут быть достаточно уверены, что исходный код, который они имеют, соответствует скомпилированному файлу. Если вы используете что-то, что сделал кто-то другой, то вы никогда не можете быть уверены.

Как уже упоминалось в комментариях, вполне разумно хранить сторонние библиотеки DLL в вашей системе управления версиями, особенно если у вас нет исходного кода для них. Я также работал над проектами, в которых мы хранили файлы дистрибутива (.tar.gz и т. Д.) Для различных библиотек с открытым исходным кодом в системе управления исходным кодом, затем у меня была целая система Makefile s, которая создавала эти библиотеки как часть цель построения всего.

Answer 4

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

Чтобы принять версию, которая находится в ветви, с которой вы объединяетесь, используйте:

svn resolve --accept=theirs-full path/to/filename

Чтобы принять версию, которая ранее была в текущей ветке, используйте:

svn resolve --accept=mine-full path/to/filename

Иногда SVN откажется использовать theirs-full с предупреждением:

svn: warning: W195024: Inapplicable conflict resolution option given for conflicted path

потому что SVN - это кусок дерьма, когда дело доходит до слияния. В этом случае вам придется копировать файлы вручную, как в принятом ответе https://stackoverflow.com/a/410767/2279059,, а не использовать параметры командной строки, предназначенные для того, что вы пытаетесь сделать. Если вы знаете, что оба файла идентичны (но SVN по-прежнему помечает их как конфликтные по уже указанным причинам), вы также можете использовать

svn resolve --accept=working path/to/filename

Хотя это, в случае идентичных файлов, фактически совпадает со всеми другими командами, SVN не будет трусливо отказываться от его выполнения. Имеет ли это смысл? Нет, это не так. Смирись с этим.

Answer 5

Целесообразно также иметь двоичные файлы в управлении версиями:

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

• Двоичный файл блокируется при отпускании.

Чтобы эта работа работала, бинарный файл должен всегда соответствовать источникам. Так что, если вы объединили источники, вам нужно восстановить двоичный файл из них, выбор одного из двоичных файлов из объединенных версий не подходит.

Answer 6

Так что, если у вас есть * .dll в отдельной папке, это гораздо проще сделать следующим образом:

1. Непосредственно перед созданием изменений обновите папку * .dll, а также обновите свои источники, если вы уверены, что ваши коллеги передают только скомпилированный исходный код. (в случае конфликта (что может быть вашей ошибкой в ​​тот момент, когда вы что-то изменили перед обновлением до последней версии))
2. Сделай свою сборку.
3. Непосредственно передайте результат.

В качестве альтернативы:

не создавайте путь к каталогу, создавайте его где-то снаружи, пока вы не будете довольны результатом.

Затем действуйте следующим образом:

1. Обновите вашу рабочую копию папки dll (если есть какой-либо конфликт, это ваша вина, и решите конфликт, оставив свои)
2. Скопируйте ваши рабочие .dll в рабочую копию
3. Сообщите своим коллегам, что вы совершите новую ревизию (вы можете пропустить этот шаг)
4. Если вы столкнетесь с конфликтом, поручите свою работу. Это должна быть их вина.

Теперь у вас есть две возможности:

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

5б. Вы работаете так, как должны работать ... Прочитайте файл журнала и выясните, кто также зафиксировал за короткое время, необходимое для копирования вашей работы в папку, и нажал коммит. Поговорите с этим коллегой. Договориться о дальнейших действиях.

Answer 7

Убедитесь, что в ваших dll свойство svn:mime-type установлено на application/octet-stream или другой нетекстовый тип.

svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll

Вам по-прежнему придется разрешать конфликты, когда они возникают.

И проверьте главу документации Тип содержимого файла .