Какую стратегию использования SVN выбрать для небольшой команды?

Question

[prometian]

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

Comments

[pi314]

Озвученные опасения выглядят весьма правдоподобно. На сегодня лучшая стратегия работы с SVN - отказ от нее и переход на git, с использованием ориентированного на git-flow варианта. А в остальном лучшая практика (не важно, с кoторой именно VCS) - маленькие атомарные коммиты, предварительно смердженные локально с главной веткой и протестированные на работоспособность. Плюс, конечно, копилка на кофе, в которую каждый уронивший главную ветку непротестированным коммитом бросает денежку... для закрепления лучшей практики, так сказать ))

[prometian]

А каждый разработчик при этом работает в своей ветке?

[pi314]

prometian, В целом, да, но не обязательно. Это зависит от того, над чем работает. Gitflow предлагает идею иерархически организованных (по критичности) веток. Master - в нее мерджатся только готовые версии, n release веток - это то, что в SVN бычно помечают тегами, т.е. релизы, предназначенные для тестирования, develop - это то, что в SVN называют транком, святой Грааль. Эту ветку всегда поддерживают актуальной и работоспособной. Из нее после модульного и интеграционного тестирования код мерджится в release. Плюс к этому, любое необходимое количество hotfix веток от соотв. release ветки, если спасение человечества не может подождать до следующего релиза, потом мерджится либо с release веткой, либо с master - смотря как организован процесс и версионирование. И, наконец, любое количество feature веток. Они создаются от develop, в них и работает один или несколько разработчиков, работающих над этой фичей. Из них код мерджится в develop, и далее по описанной выше схеме. Это так сказать, полная идея. На практике не всегда нужен такой зоопарк, так что можно адаптировать только то, что подходит под конкретный процесс разработки.