SVN: персональные ответвления для каждого разработчика?
Я буду честен, ответвления SVN пугают меня. Последний проект, что я работал, на котором использовал их экстенсивно, я, казалось, потратил половину моего времени, тестируя мое работавшее ответвление, делая фиктивное слияние в соединительную линию, делая реальное слияние - только, чтобы найти, что кто-то еще только что фиксировал, в то время как я делал это, и я должен был обновить и запуститься.
На том конкретном проекте ветвление было сделано на разработчика... была соединительная линия, и затем Вы имели свое персональное ответвление, работали над задачей и объединились, диапазон изменений въезжают задним ходом. Это казалось ужасающим, поскольку необходимо было проверить каждый раз, что последний пересмотр в ответвлении был то, что Вы объединились.
Действительно ли эта парадигма на самом деле хороша, и я просто не получил ее, так как я не привык к командной строке использование SVN? Или действительно ли это была ужасная система?
14 ответов
С Subversion, я использую "рабочие ветви(ы)", которые принадлежат команде и разделяются всеми членами команды, как описано в большой Версия управления для нескольких гибких команд статьи и проиллюстрировано ниже:
Я горячо рекомендую прочитать всю статью, это действительно стоит прочитать.
С чем-то другим, чем Subversion, я могу рассмотреть возможность использования "ветвей функции", но, честно говоря, я не вижу смысла личных ветвей на разработчика (и это не имеет смысла для меня, чтобы выйти за рамки гранулярности функции).
.На каждую ветвь разработчика действует парадигма. Основное преимущество, которое я обнаружил, заключается в том, что они позволяют вам проверять текущую работу и, следовательно, получать к ней резервную копию, доступ к ней других людей в случае болезни и т.д., не нарушая основной ствол.
Ветви сами по себе не являются проблемой, проблемы заключаются в управлении слияниями. Что я делал в прошлом, так это использовал маркер слияния (мягкая игрушка или фигурка действия хорошо работает - тот, кто держит маркер, может сделать слияние в основной ствол) или имел очередь слияний в dev wiki, в основном, имел только одно устройство, сливающееся в основной ствол за раз.
Это казалось ужасным, поскольку вам приходилось каждый раз проверять, какая последняя ревизия в вашей ветке была, когда вы сливались.
Я просто хотел указать, что вам больше не нужно этого делать: SVN 1.5.0 и выше поддерживает отслеживание слияний.
Основным преимуществом, как я вижу, от наличия ветки для каждого разработчика является то, что вы можете ввести политику частой проверки - конечно, каждый вечер проверять код - независимо от состояния их кода, так как они не сломают чужую сборку, не говоря уже об основной линии разработки.
Это означает, что у вас есть ночная резервная копия работы людей, и разработчику проще вернуться к (частично) работающей версии их разработки, если он совершит ошибку или столкнется с проблемой при реализации алгоритма.
Это также обеспечит то, что только полностью одобренный и протестированный код (предполагая, что вы делаете просмотр кода и юнит-тестирование) будет проверяться в основной строке.
Я согласен, что накладные расходы на слияние могут быть обременительными, но если все постоянно (ну хотя бы пару раз в неделю, желательно один раз в день) интегрируются из основной строки в свою ветку, то влияние слияния из ветки разработчика должно быть минимальным.
.Я использовал подобную практику в прошлом.
Если несколько разработчиков обновляют одни и те же файлы кода, то это может не быть проблемой контроля версий. Я ничего не знаю о вашем коде, но не может ли он быть слишком монолитным и недостаточно модульным? Таким образом, когда задания выполняются, разработчики не всегда наступают на изменения друг друга
.Честно говоря, вы, наверное, хотите что-нибудь другое, например, git.
Я никогда не пользовался branch-per-developer. Для меня эта идея не имеет смысла.
Для начала вам следует выстроить свою команду разработчиков так, чтобы люди имели склонность работать над разными частями исходного кода. Если все постоянно редактируют одни и те же файлы, никакая технология не поможет вам координировать всех.
SVN делает отличную работу по слиянию правок разных людей в те времена, когда люди работают над одними и теми же файлами. Пишите юнит-тесты, чтобы убедиться, что продукт слияния кода все еще работает.
Я использую ветки для поддержки текущей версии кода во время разработки следующей версии.
.Если вам действительно нужно делать ветки для каждого разработчика, то вам действительно стоит использовать Git, он спроектирован с нуля, чтобы управлять каждой "рабочей копией" разработчика как собственным репозиторием, а слияние встроено в его ядро
.Проблема с ветвями для разработчиков заключается не в самих ветках, а (как вы сами написали) в их слиянии. К сожалению, слияние все еще является проблемой для svn. В то время как ветки разработчика имеют смысл, инструмент является проблемой. Я использую git (с git svn), так как некоторое время назад ветки разработчиков стали естественными, потому что поддержка слияния лучше так - вы можете просто произвести слияние, и в то время как конфликты слияния всё ещё происходят, они (по моему опыту) происходят гораздо меньше и гораздо менее болезненны.
.Попробуйте использовать Mercurial. Он не имеет центрального репозитория по проекту.
Нет конфликтов коммитов, потому что нет push.
.Ваша парадигма должна соответствовать сродству инструмента. Subversion - неправильный инструмент для этой парадигмы, потому что слияние в Subversion - это PITA. Измените свою парадигму или переключитесь на Git или Mercurial.
.Мы используем одну ветвь разработки для большинства повседневных операций. Из нашего опыта мы узнали, что когда один разработчик работает над действительно большим проектом, который расширяет несколько модулей, он должен создать свою собственную ветку и работать из нее. В противном случае, у нас не было проблем с запуском из одной ветки svn, и это значительно упрощает работу. Кэвит, у нас есть небольшая команда из 3 разработчиков + случайный подрядчик
.Я работаю с CVS и SVN уже почти 10 лет и использование ответвлений для каждого разработчика меня тоже пугает :).
Все команды, в которых я работал, использовали ствол для ежедневной разработки и ответвления для замороженной/бета/релизной версии (иногда большие новые, независимые возможности реализовывались в отдельном ответвлении).
Ответвления были слиты обратно в ствол одним из разработчиков (SVN) или автором (CVS).
И поскольку слияние как повседневная практика, так как Subversion 1.5 легка, то не должно быть никаких проблем, чтобы произвести слияние.
.] Я использовал аналогичную стратегию филиала в SVN в моих последних командах (маленькие команды: в настоящее время 4 devs large) и принял подход в TFS в моей текущей команде.[
] [] Ветвь на каждый рабочий элемент багтрекера. [
] [] Эта стратегия предоставляет разработчику преимущество изолированной среды управления исходным текстом, в которой (s) он может стучать по коду, ревертировать и т.д., используя роскошь, которую предоставляет SVN, но никогда не позволяет разработчику дрейфовать слишком далеко от магистральной линии в стволе. Развитие давно существующих возможностей за пределами ствола весьма затруднено. Идея подчёркивается тем, что предполагаемый объём + длительность рабочего элемента отслеживания ошибок не должен значительно превышать один рабочий день.[
]. [] На практике я обнаружил, что это приводит к тому, что небольшие модификации довольно часто сливаются в ствол. Учитывая небольшую природу моих команд, мы редко топчем друг друга на ноги, чтобы слить их, так что конфликты, как правило, не являются проблематичными. [
] [] Я скажу, что эта система была довольно удобна в SVN: меньше в TFS, которая, похоже, не так изящно обрабатывает слияния, как SVN 1.4, не говоря уже о 1.5+. [
].