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

Question

Рассмотрим ситуацию.Я хочу зафиксировать измененный файл в SVN и увидеть, что кто-то еще зафиксировал тот же файл после того, как я его проверил, поэтому мне нужно «обновить» и объединить изменения.Пока я это делаю, кто-то снова фиксирует тот же файл, поэтому, когда я пытаюсь зафиксировать объединенный файл, мне нужно снова обновить.

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

Answer 1

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

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

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

Answer 2

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

---

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

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

Например, у нас был уникальный файл свойств, подобный этому, для всего приложения. Он даже разбил Eclipse, чтобы сравнить две версии файла! :-) Так что некоторые разработчики не будут сравнивать и объединять его, а будут совершать действия, превосходящие другие! Мы разделили файл, один файл свойств на модуль, и проблемы исчезли.

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

---

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

Answer 3

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

из svn book http://svnbook.red -bean.com / ru / 1.5 / svn.advanced.locking.html

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

Answer 4

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

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

Другими словами:

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

tl; dr: проблема будет исправленасам по себе.

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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