Subversion - должен ли кто-нибудь развиваться из ствола?

Ответ 1

Существуют две основные стратегии:

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

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

Как обычно, никакого определенного ответа нет!

Ответ 2

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

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

Ответ 3

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

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

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

Посмотрите также на следующий сайт:

http://www.cmcrossroads.com/bradapp/acme/branching/

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

• S1. Магистраль
• S2. Параллельное обслуживание/разработка
• S3. Перекрывающиеся релизы
• S4. Док-станция
• S5. Поэтапные линии интеграции
• S6. Изменить очереди распространения
• S7. Сторонняя кодовая линия
• S8. Внутренние/внешние линии

Ответ 4

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

Ответ 5

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

Хотя метод, который вы описываете, с каждым разработчиком, имеющим свою ветвь, ближе к Git, чем Subversion. Если вы предпочитаете работать, я бы рекомендовал вместо этого использовать Git.

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

Ответ 6

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

Однако наша система всегда завораживает и часто использует CI. Каждый разработчик должен знать цикл update/rebuild/retest/commit (не то, чтобы он был надежным, но он работает достаточно хорошо).

Hmph, мне больно, когда я думаю о том, сколько из наших программных продуктов работает "Хорошо, достаточно".

Ответ 7

Там должен быть аргумент, что разработчики должны будут работать на багажнике.

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

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

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

Ответ 8

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

После бета-тестирования мы выпустили prod.

Ответ 9

Сейчас я работаю над версией 3.0 нашего продукта и проверяю, что мой код изменяется в багажнике. Релиз продолжается еще на несколько недель.

Сотрудник экспериментирует с некоторыми функциями, которые могут сделать его в 4.0, но определенно не в 3.0. Она проверяет свои вещи на отдельную ветку. Было бы неправильно проверять этот материал в багажнике.

Другой сотрудник исправляет ошибки в версии 2.5, которые мы уже отправили клиенту. Он проверяет их в ветке 2.5 по понятным причинам.

Итак, чтобы ответить на заголовок вопроса (если все будут развиваться из ствола, мой ответ - нет. HTH

P.S. о слиянии. Мы могли бы выборочно объединить некоторые вещи из ветки 2.5 в магистраль позже, но не от ствола до ветки. Слияние между хостом и ветвью 4.0 может идти в обоих направлениях.

Ответ 10

Как Нил Баттерворт сказал, это зависит; существует несколько допустимых способов.

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

Если вы заинтересованы в том, как мы это применили, в есть более подробная информация. (Мне бы очень хотелось повторить слишком много...:)

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

Ответ 11

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

Я думаю, что это довольно хорошо охвачено этим вопросом

Ответ 12

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

Ответ 13

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

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

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

Ответ 14

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

Ответ 15

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

Думаю, я также хотел бы добавить, что если вы развиваетесь в ветких, вы не можете быть проворным. Развитие в отраслях работает только в водопаде.

Ответ 16

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

• Если вы используете Subversion, неустойчивая соединительная линия, вероятно, будет работать лучше для вас.
• Если вы используете GIT, стабильная соединительная линия будет намного проще, чем Subversion.

Ответ 17

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

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

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