Subversion merge: всегда заменять файл новой ревизией

Question

при выполнении слияния, есть ли какое-либо свойство subversion, которое я могу установить, чтобы всегда заменять файл более новым ervision (вместо того, чтобы делать diff и вызывать конфликт, когда он не может слиться)?

Множество файлов, о которых я говорю, это файлы проекта C # (* .csproj). Эти файлы всегда вызывают конфликт. Я хотел бы, чтобы эти файлы всегда обновлялись до той ревизии, которая новее, когда я делаю слияние.

Answer 1

Да.

Если вы укажете --accept theirs-full в качестве опции для svn merge, вы можете внести изменения, сделанные на стороне хранилища, и потерять свои в случае конфликта. 1007 *

РЕДАКТИРОВАТЬ: Если подумать, я согласен, что вы, вероятно, не должны этого делать. См. SVN FAQ для рекомендуемого способа сделать это.

Answer 2

У нас есть эксклюзивные блокировки для нескольких типов файлов, один из которых - cproj. У нас также есть рабочая практика, при которой разработчики только удерживают блокировку в течение минимального промежутка времени, то есть, если вы добавляете класс, затем захватываете блокировку, добавляете пустую заглушку класса (которая компилируется!), А затем освобождаете. Я знаю, что многие недовольны эксклюзивными блокировками в Subversion, но это очень хорошо работает на малых и средних проектах. Не уверен, хотел бы я расширить его до больших проектов.

Answer 3

Я не знаю, как автоматически иметь svn / tortoisesvn "Accept Theirs" автоматически при конфликте слияния. Делать это вручную - вот как я всегда справлялся с конфликтом слияния. Вы должны иметь возможность, с помощью TortoiseSVN, разрешить конфликт, сказав Tortoise вращаться с «их» файлом, уничтожив все сделанные вами изменения.

Answer 4

В идеале вы вообще не будете фиксировать файлы проекта, только исходные и необходимые библиотеки для компиляции. Затем вы можете добавить свои файлы проекта в svn: ignore, и вам больше не придется об этом беспокоиться.

Другие разработчики вашего проекта могут свободно создавать файл проекта C # вокруг существующего рабочего пространства, настраивать его для компиляции и вносить любые локальные изменения в настройки проекта, которые они хотят, не нарушая вашу сборку. Файлы проекта C # немного громоздки, но в худшем случае это 10-15 минутная работа, и вам нужно сделать это только один раз.