Что происходит, если файл, я хочу согласиться на SVN, обновляется так часто, мне не удается сделать слияние достаточно быстро?

Не смог бы просто заблокировать файл?

из книги SVN http://svnbook.red-bean.com/en/1.5/svn.advanced.locking. .html

svn lock banana.jpg -m "Editing file for tomorrow's release."

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

Сначала позвольте нам полагать, что это не игра, иначе не сделано иначе нарочно, чтобы разозлить вас и украсть ваш хороший стул, когда вы вышли с гневом ...
Но нужно. ; -)

Если это произойдет, файл сложен для объединения (Big) и обновляется очень часто (также станет большим).

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

Например, у нас был уникальный файл свойств, например, для всего приложения. Это даже разбило затмение, чтобы сравнить две версии файла! :-) Так что некоторые разработчики не сравниму и сливают его, но совершить переопределение коммитаров другого! Разделив файл, один файл свойств на модуль, и проблемы ушли.

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

Как временное решение, вы можете синхронизироваться с людьми , чтобы они давали вам открытое окно, чтобы объединить и совершать. Но проблема, как правило, продолжает появляться, пока команда не рестовит ее определенно. ; -)

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

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

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

Если файл часто записывается, возможно, он не должен находиться в системе управления версиями? Мой тест для этого: «Могу ли я всегда дать значимое английское описание каждой ревизии (то есть тэг)?» - если нет, то, вероятно, его не следует контролировать.

Хотя я полностью согласен с @ OrbMan, я могу предложить использовать команду «Get Lock», но только в качестве последнего средства.

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

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

Это сказано, что SVN позволяет людям сломать замки. В случае, если кто-то заблокировал файл и забыл разблокировать его перед поездкой, например. Итак, даже если вы заблокируете его, кто-то может сломать замок и зафиксировать их код до того, как можно провести слияние. Но если кто-то нарушает названные пользователи блокировку и сначала совершайте, не проверяя с ними, это, вероятно, еще хуже пример отсутствия взаимосвязанной связи и снова - это больше проблем с «людьми».

Если файл выступает так часто, может быть, он не должен находиться под контролем источника? Мой тест на это: «Могу ли я всегда дать значимое английское описание каждого ревизии (то есть тег)?» - Если нет, это, вероятно, не следует контролировать.

Это не решение, а обходной путь : используйте GIT-SVN в качестве локального клиента к репозитории Subversion.

Whilst it is fairly common for developers to be working on the same file, it hardly ever happens that you need to perform an update twice in a row, because of people committing before you had a chance to finish the merge.

And if that's the case, and you were to have 5 people working on the same file (crazy in its own right), making micro-commits every 5 minutes, I'd say you got other problems you should worry about and need to restructure your code as well as give them (your peers) a right 'bollocking'.

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

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

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