SVN: личные ветки для каждого разработчика?

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

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

Действительно ли эта парадигма хороша, и я просто не понял ее, так как я не привык к использованию SVN в командной строке? Или это ужасная система?

Ответ 1

С Subversion я использую "рабочие ветки", которые принадлежат команде и разделяются всеми членами команды, как описано в большой Управление версиями для нескольких гибких команд и показано ниже:

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

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

Ответ 2

Я никогда не использовал branch-per-developer. Идея для меня не имеет смысла.

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

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

Я использую ветки для поддержки текущей версии кода при разработке следующей версии.

Ответ 3

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

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

Ответ 4

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

Я просто хотел указать, что вам больше не нужно это делать: SVN 1.5.0 и поддержка отслеживания слияния поддержки.

Ответ 5

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

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

Он также гарантирует, что только проверенный и проверенный код (при условии, что вы выполняете проверку кода и модульное тестирование) проверяется в основной строке.

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

Ответ 6

Честно говоря, вы, вероятно, захотите что-то другое, например git.

http://git-scm.com/

Ответ 7

Я использовал подобную практику в прошлом.

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

Ответ 8

Я работаю с CVS и SVN в течение почти 10 лет, и использование ветки на разработчика меня тоже пугает:).

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

Филиалы были объединены обратно в магистраль одним из разработчиков (SVN) или автором (CVS).

И потому, что слияние как ежедневная практика, так как Subversion 1.5 легко, не должно быть никаких проблем для слияния.

Ответ 9

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

Ответ 10

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

Ответ 11

Я использовал аналогичную стратегию ветвления в SVN в моих последних командах (небольшие команды: текущий - 4 devs large) и применили подход в TFS к моей текущей команде.

Мы ведем работу по работе с отслеживателем ошибок.

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

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

Я скажу, что эта система была довольно удобной в SVN: менее в TFS, которая, похоже, не обрабатывает слияния так же изящно, как SVN 1.4, даже не более 1,5 +.

Ответ 12

Попробуйте использовать Mercurial. Он не имеет центрального репозитория по дизайну.

Также отсутствуют конфликты с фиксацией, потому что нет push.

Ответ 13

Ваша парадигма должна соответствовать близости инструмента. Subversion - неправильный инструмент для этой парадигмы, потому что слияние в Subversion - это PITA. Измените свою парадигму или переключитесь на Git или Mercurial.

Ответ 14

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