Svn разработка рабочего процесса

Question

В настоящее время я работаю над проектом для двух человек, в котором мы используем Subversion в качестве нашего Source Control. Прямо сейчас мы оба создаем ветки и проводим нашу разработку в этих ветках, а затем объединяем эти изменения в копию транка перед фиксацией транка.

Проблема, с которой мы сталкиваемся, заключается в огромных затратах на обновление всего.

Пример нашего рабочего процесса

1. Я запускаю Обновление на своей внешней копии, чтобы получить последние обновления
2. Я объединяю обновления ствола в мою ветку
3. Я работаю над своей веткой
4. Я сливаю свои изменения в багажник
5. Я обновляю транк, чтобы увидеть, есть ли новые обновления
6. Я совершаю

Проблемы

1. Трудно отследить, какая ревизия была объединена, даже когда я явно записываю i в журнал
2. Иногда у меня есть полностью обновленная ветка, но я не могу объединить обновления обратно в транк для фиксации.

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

Спасибо

Answer 1

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

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

Answer 2

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

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