Эффективное микро-сотрудничество с членами команды в Subversion?

Question

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

Похоже, у меня есть 3 плохих варианта и 0 хороших?

• передайте его в транк, чтобы он мог получить мои изменения. нет! код не закончен
• создайте рабочую ветку и сделайте коммит там. Не стоит беспокоиться, когда я просто работаю над небольшой функцией.
• сделайте svn diff, отправьте ему патч через ssh и попросите его применить его. Все еще не стоит хлопот

Какой стандартный способ обработки этого в Subversion?

Также: инструменты DVCS, такие как git, справятся с этой, казалось бы, простой ситуацией лучше, чем Subversion?

Answer 1

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

/
`---> trunk/
`---> branches/
`---> users/
            `---> john/
                      `---> trunk/
                      `---> branches/
            `---> mary/
                      `---> trunk/
                      `---> branches/

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

Answer 2

Я делал это в прошлом, используя метод send-a-patch. Однако позже становится трудно согласовать изменения.

Я сейчас использую Git, и это определенно помогает в этой ситуации, это очень естественно. Я могу попросить корову-орка извлекать конкретные коммиты из моего репозитория и помогать работать с ними. Каждый из нас может делать коммиты, затем я могу вытащить коммиты из их репозитория, использовать git rebase -i, чтобы все организовать, и продолжить оттуда.

Answer 3

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

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

Вот два сценария, которые работают для меня. Они принимают структуру хранилища, такую ​​как:

project/trunk/
       /branches/some_branch
                /another_branch

Для работы с другой структурой потребуются некоторые корректировки.

# script 1: svn_wc2b (working copy to branch)
trunk_url=`svn info | grep URL | sed 's/URL: //'`
project_base=`svn info | grep URL | sed 's/URL: //;s/\/trunk.*//'`
branch_name=my_working_copy

svn cp $trunk_url $project_base/branches/$branch_name -m "Creating temporary branch for working copy."
svn switch $project_base/branches/$branch_name

Тогда, когда вы захотите поделиться своей рабочей копией транка, вы наберете:

svn_wc2b  # creates branch, switches to it    
svn commit # commit your in-progress work to the branch

Чтобы получить код, другому разработчику просто нужно набрать:

svn switch http://repository/project/branches/my_working_copy

Когда другой разработчик завершит работу и внес изменения, используйте скрипт, подобный следующему:

# script 2: svn_b2wc (branch to working copy)
branch_revision=`svn log -q --stop-on-copy | grep '^r[0-9]' | sed 's/^r//;s/ |.*//' | tail -n 1`

if [ -e $branch_revision ] && [ -e $1 ]
then
  echo "Couldn't get branch creation revision number. Check svn log --stop-on-copy and use svn_b2wc <revision_number>"
  exit
elif [ -e $branch_revision ]
then
  branch_revision=$1
fi

branch_url=`svn info | grep URL | sed 's/URL: //'`
project_base=`svn info | grep URL | sed 's/URL: //;s/\/branches.*//'`
branch_name=my_working_copy

svn switch $project_base/trunk
svn merge -r $branch_revision:HEAD $branch_url .
svn delete $branch_url -m "Deleting working copy branch."

Из вашего каталога, который был переключен в вашу ветку, вы набираете:

svn_b2wc # switch back to trunk, merge branch changes, delete branch

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

Answer 4

Обычно я передаю по электронной почте (или иным образом передаю) оскорбительный код моему коллеге, предполагая, что у него нет изменений в этом подразделении (или этих подразделениях), которые не могут быть временно перетасовал Затем он / она копирует мои изменения и отправляется на работу. Ничего более или менее этого. Позже, когда они делают diff, они видят мои изменения в их diff, обновляют из репозитория, чтобы перезаписать мой код, с которым они помогли, и вуаля. Все возвращается на круги своя.