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

Question

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

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

Редактировать:

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

Answer 1

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

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

имя файла.мое

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

имя файла.rolldrev

Это файл, который был БАЗОВОЙ версией до того, как вы обновили свою рабочую копию.То есть файл, который вы извлекли перед внесением последних изменений.

имя файла.rNEWREV

Это файл, который ваш клиент Subversion только что получил с сервера, когда вы обновили свою рабочую копию.Этот файл соответствует ГОЛОВНОЙ версии репозитория.

Здесь OLDREV - это номер редакции файла в вашем каталоге .svn, а NEWREV - это номер редакции ЗАГОЛОВКА репозитория.

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

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

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

svn resolved filename

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

Answer 2

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

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

Answer 3

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

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

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

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

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 имеют svn:mime-type свойство, установленное в application/octet-stream или какой-то другой нетекстовый тип.

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

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

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

Answer 7

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

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

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

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

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

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

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

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

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