разрешение svn двоичные конфликты
Вы пытаетесь получить доступ к полю модели discounted_price_pretax_cents на сервисном объекте, у которого нет этого поля.
Если PricingComputed используется в качестве сервисного объекта (объекта, выполняющего бизнес-логику), вам, вероятно, не следует передавать его в представление. Вместо этого создайте объект данных (например, Struct) с данными, которые необходимы в представлении, или передайте модель (в этом случае, вероятно, @order).
Вы также можете обернуть @order в декоратор, который будет преобразовывать значения и настраивать его так, чтобы они отображались в виде, но я думаю, что это не так.
5 ответов
Как упомянуто в других ответах здесь: Вы не должны присваивать версию своему сгенерированному dlls во-первых. Но если действительно необходимо присвоить версию им, затем можно разрешить конфликт, не используя различный инструмент, который удаляет dll файлы:
Для каждого противоречивого файла Подверсия помещает три дополнительных неимеющих версию файла в Вашу рабочую копию:
filename.mine
Это - Ваш файл, поскольку он существовал в Вашей рабочей копии перед обновлением рабочей копии — то есть, без маркеров конфликта. Этот файл имеет только Ваши последние изменения в нем. (Если бы Подверсия полагает, что файл unmergeable, .mine файл не создается, так как это было бы идентично рабочему файлу.)
filename.rOLDREV
Это - файл, который был ОСНОВНЫМ пересмотром перед обновлением рабочей копии. Таким образом, файл, который Вы проверили перед созданием последних редактирований.
filename.rNEWREV
Это - файл, который Ваш клиент Подверсии просто получил от сервера, когда Вы обновили свою рабочую копию. Этот файл соответствует ГЛАВНОМУ пересмотру репозитория.
Здесь OLDREV является количеством пересмотра файла в Вашем .svn каталоге, и NEWREV является числом пересмотра ГЛАВЫ репозитория.
Теперь, для разрешения такого конфликта удалите дополнительные файлы, которые Вы не хотите:
- если Вы хотите сохранить свой собственный dll, удалите файлы filename.rOLDREV, filename.rNEWREV
- если Вы хотите сохранить dll от репозитория, удалить файлы filename.rOLDREV и filename.mine, то скопируйте filename.rNEWREV в имя файла
после этого выполниться
svn resolved filename
сказать Подверсию, что Вы разрешили конфликт сами.
Если это - DLL, который Вы СОЗДАЕТЕ (а не внешний, у Вас нет источника для), затем, источник должен быть в управлении исходным кодом, не двоичном файле.
Если Вы не хотите включать его в тот конкретный репозиторий затем, можно включать его как svn:external.
Обычно Вы не сохранили бы свой собственный скомпилированный DLLs в управлении исходным кодом вообще. У Вас есть определенная причина, что необходимо сделать это?
Я настроил свои среды разработки так, чтобы кто-либо мог создать любой из моих компонентов проекта независимо от кого-либо еще. Таким образом единственной вещью, которая находится в моей системе управления исходным кодом, является мой исходный код. Это обладает многими преимуществами:
- Это избегает конфликтов двоичного файла при попытке зарегистрироваться в DLLs или EXEs
- Объем данных, прослеженных Вашей системой управления исходным кодом, намного меньше, делая его быстрее
- Когда разработчики всегда создают свой собственный DLLs, затем они могут быть довольно уверены, что исходный код, который они имеют, соответствует скомпилированному файлу. При использовании чего-то, что кто-то еще создал, то Вы никогда не можете быть уверены.
Как упомянуто в комментариях, может быть совершенно разумно сохранить третье лицо DLLs в Вашей системе управления исходным кодом, особенно если у Вас на самом деле нет источника для них. Я также работал над проектами, где мы хранили файлы распределения (.tar.gz и т.д.) для различных библиотек с открытым исходным кодом в управлении исходным кодом, затем имел целую систему Makefiles, который создал те библиотеки как часть сборки - все предназначается.
Разумно также иметь двоичные файлы в управлении версиями:
Это избегает стычки восстановления для людей, которые только используют двоичный файл.
Двоичный файл закрепляется, когда Вы выпускаете.
Для создания этой работы, двоичный файл должен всегда соответствовать источникам. Таким образом, при слиянии источников, необходимо восстановить двоичный файл от них, выбирание одного из двоичных файлов от объединенных версий не сделает.
Удостоверьтесь, что Ваши dlls имеют svn:mime-type набор свойств к application/octet-stream или некоторый другой нетип текста.
svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll
Необходимо будет все еще на самом деле разрешить конфликты, когда они происходят.
И проверьте главу Типа контента Файла документации.