Как предотвратить слияние Subversion бинарных файлов?

Question

Нам нужно сохранить .dll в нашем репозитории. Наша команда довольно часто сталкивается с конфликтами SVN для файлов .dll, и это очень раздражает. По какой-то причине, даже несмотря на то, что mime-тип .dll установлен в application / octet-stream, svn все еще пытается объединить их.

Из того, что я нашел здесь (который, клянусь, как и было раньше), говорится, что пока тип mime не является текстовым, svn не будет пытаться объединить их. Но просмотр моих dll говорит мне, что svn объединяет мои файлы application / octet-stream (по крайней мере, я предполагаю, что SVN объединяется, не знаю, почему возникнет конфликт без объединения). Почему, черт возьми, svn пытается объединить двоичный файл? Это просто глупо ...

Кто-нибудь сталкивался с этой проблемой?

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

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

Для справки: я использую черепаху 1.5.0 и Ankh.

Answer 1

Чтобы убедиться, что я вас правильно понимаю, давайте повторим:

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

AFAIK, svn способ сделать это будет:

• запустить 'svn update --accept itss-full' для двоичных файлов
• запускать регулярное 'svn update' для всей локальной копии

Я не думаю, что это можно сделать одной командой, и я также не думаю, что это может быть выполнено в одной команде, так как эта первая команда может потерять ценные данные.

Answer 2

У нас та же проблема с определенными файлами.

CVS очень хорошо справляется с этой проблемой, но, к сожалению, моя компания переходит на Subversion.

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

В файле .CVSwrappers введите *.fileext -k b -m COPY. Это говорит CVS всегда делать резервную копию файла в локальном репозитории и загружать новую версию при возникновении конфликтов. Так элегантно.

Эквивалентной настройки для SVN не существует. Если кто-нибудь знает как, напишите пожалуйста.

Answer 3

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

Если вам нужно архивировать двоичные файлы релизов (или аналогичные), вы должны сделать это в теге или ветке релиза, но не в транке.

Answer 4

Вы уверены, что он пытается объединить их? Больше похоже на то, что вы получаете конфликт, потому что Subversion не знает, как их объединить (чего вы в любом случае не хотите).

Что именно вы хотите, чтобы произошло, если у вас есть локально модифицированная dll, и кто-то совершает ту же самую dll, прежде чем вы это сделаете? Что вы ожидаете случиться? Это, очевидно, конфликт, и Subversion не знает, хотите ли вы, чтобы он использовал вашу dll или их dll.

Answer 5

Эти dll-файлы, они создают вывод из реальных проектов?

Если это так, их вообще не следует помещать в SVN. Subversion должна содержать исходные файлы, и сервер сборки / dev может собирать dll оттуда.