А вот как у вас модно

[metaclass]

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

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

PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.

Comments

[dmzlj.livejournal.com]

Мера борьбы - как только удается получить стабильную версию de facto (а такое периодически случается), она отмечается специальным тегом и вот это предъявляется как последняя версия потенциальным заказчикам. Так что бамбук в результате никто не курит.

Да ну? А фиксы на нее коммитить по результатам тестов?

Из-за недокоммиченности проблемы минутные, если сразу удалось заметить. А если не сразу, то проблема может быть зарыта сколь угодно глубоко.

[psilogic.livejournal.com]

[ Да ну? А фиксы на нее коммитить по результатам тестов? ]

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

Не сразу заметить - так не бывает. Весь проект собирается целиком 1-2 раза в день и еще N раз на машинах разработчиков. Если что-то не закоммичено, этот факт остается незамеченным максимум несколько часов.

[dmzlj.livejournal.com]

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

Что-то делать остается только тем, кому надо фиксить в своей зоне ответственности.

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

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

[psilogic.livejournal.com]

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

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