![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
А вот как у вас модно
работать с системами контроля версий? Конкретно, с subversion, потому что в меркуриале и прочих DVCS можно хоть обкоммитится до одури - пока в другой репозиторий не закинешь, этого никто не увидит.
Я как-то склоняюсь к "сделал независимый мелкий кусок - тут же закомитил", даже если там пару букв всего поменялось. Т.е. билд стараться не ломать принципиально, но накапливать изменения на "один огромный коммит на всю фичу" не хочу.
PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.
Я как-то склоняюсь к "сделал независимый мелкий кусок - тут же закомитил", даже если там пару букв всего поменялось. Т.е. билд стараться не ломать принципиально, но накапливать изменения на "один огромный коммит на всю фичу" не хочу.
PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.
no subject
Здесь я имею в виду специфические трудности, которые возникают при работе с данным инструментом и к которым надо приноровиться, понять, как с ними дешево бороться. Ну как невозможность легко отследить переименование в CVS - наверняка в "черепашке" есть свои подобные заморочки.
[ Окупаться начнет не использование нового контроля версий, а более упорядоченная разработка. ]
Я это понимаю. Вопрос в том, за сколько оно окупится. В наших проектах выгода неочевидна. Была бы очевидна - перескочили бы со свистом. По сравнению с ежедневным переключением с C++ на Java потом на Delphi потом обратно - это не проблема.
no subject
Ну ведь на этот вопрос нельзя ответить в общем? Можно только вести учет времени, потраченные на отдельные активности разными людьми, и смотреть сколько времени ушло на борьбу с CVS.
После CVS трудностей не будет. Наоборот, будет ощущение, что долгие годы над вами издевались, и вдруг, ВНЕЗАПНО, перестали.
У меня был опыт работы в довольно крупном проекте (1+ Gb исходников + 11 человек), где на поддержание CVS в норме время тратилось постоянно.
Писались внешние скрипты для обработки тех или иных ситуаций, постоянно были проблемы из-за недокоммиченных файлов (писались скрипты противодейтствия этому), регулярно случался code freeze, что бы стабилизировать релиз (это когда не делается новых изменений, только фиксы и вся команда с удовольствием курит бамбук).
Все это время и, соответственно, деньги. Использование нормальных инструментов большую часть этих вопросов устраняет и дает много допольнительных возможностей (несколько релизов одновременно и легкая миграция изменений между ними).
no subject
Ну возможно :)
code freeze - теперь я понял, о чем вы - да, такое у нас бывает регулярно. :)
Мера борьбы - как только удается получить стабильную версию de facto (а такое периодически случается), она отмечается специальным тегом и вот это предъявляется как последняя версия потенциальным заказчикам. Так что бамбук в результате никто не курит. А вот когда старались получить стабильную версию к заранее заданной дате - тогда да, бывали и бамбуки.
Из-за недокомиченности файлов бывают минутные проблемы:
- Мужики, у меня ### не собирается, кто последний там насрал?
- Вроде я. Сейчас проверю...
через 1 минуту:
- Все, закоммитил, собирай.
- Все, собралось.
no subject
Да ну? А фиксы на нее коммитить по результатам тестов?
Из-за недокоммиченности проблемы минутные, если сразу удалось заметить. А если не сразу, то проблема может быть зарыта сколь угодно глубоко.
no subject
В какой-то момент оказывается, что все тесты успешны, все фиксы прокоммичены, все классно - этот момент ловится и метится тегом как очередная эталонная версия.
Не сразу заметить - так не бывает. Весь проект собирается целиком 1-2 раза в день и еще N раз на машинах разработчиков. Если что-то не закоммичено, этот факт остается незамеченным максимум несколько часов.
no subject
Что-то делать остается только тем, кому надо фиксить в своей зоне ответственности.
И если нет нормальных бранчей, то неизбежно простаивание части команды. В принципе --- может быть, это даже кому-то нравится, поэтому внедрение инструментария, который позволит построить работу более эффективно, было бы воспринято в штыки.
Что до поломок от неатомарных коммитов --- то хорошо, если они сборку ломают. А если не ломают --- то может быть все, что угодно. Ну, просто баг благодаря системе контроля версий, которого могло бы не быть.
no subject
Да, я вас прекрасно понимаю, у нас когда-то так и было, и описанные вами проблемы задалбывали. Но потом просто перешли на другую организацию процесса разработки, и этот вопрос отпал сам собой. Понятно, что можно делать бранчи и даже делаем иногда, но по факту это оказывается необходимо настолько редко, что в принципе могли бы обойтись и без них.