Советы по улучшению SVN для моей рабочей среды

Question

Еще один вопрос с рекомендациями SVN, я знаю.

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

Вот проблема, с которой мы сталкиваемся:

1. Иногда несколько человек работают над одной и той же функцией / ошибкой (например, я и парень с графикой). Для того, чтобы мы синхронизировали нашу работу (например, чтобы я увидел новую картинку / css), графический парень должен зафиксировать свои изменения, и мне нужно обновить мою рабочую копию. Поэтому в конце дня у нас много ревизий для слияния из магистрали в ветку RC.

2. Часто нас просили реализовать функцию, хорошо, закончили, передали код в транк. Затем нас попросили исправить ошибку (чтобы исправить эту ошибку, она каким-то образом использует некоторый код, написанный для этой функции, но тело не запомнило ее) Хорошо, исправлена ​​ошибка, проверено, исправлено исправление ошибки в trunk Чуть позже, нам сказали, что мы не будем выпускать эту функцию, но нужно было исправить ошибку.

Есть еще несколько сценариев, но я не могу вспомнить сейчас. Как вы думаете, какие изменения улучшат наши процессы?

Привет

Джеймс

Answer 1

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

Answer 2

У вас могут быть функциональные ветви, над которыми вы и вместе с графическим парнем работаете.Удостоверьтесь, что у вас есть записанные задачи, которые вы оба будете выполнять, и когда, несомненно, будут некоторые зависимости между вами (как вы, похоже, испытываете).

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

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

Ошибки случаются после выполнения функции, никто не совершенен, но убедитесь, что у вас есть надлежащая система отслеживания ошибок и назначьте ошибки лучшему человеку для работы (обычно тот, кто больше всего знает о функции)).

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

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

HTH

Answer 3

Вероятно, сейчас самое время изменить svn на какой-то распределенный svc (например, mercurial или git). Я не использовал их, но согласно тому, что я читал об этом, у них меньше трения, когда дело доходит до слияния и ветвления, и здесь, похоже, проблема.